Commentaires de news :
Nouveau chapitre Linux : apt-get

Citation : 1337833K
Euh, c'est une blague ?

Citation : gouttegd
Tu as des problèmes de dépendances quand tu emploies un gestionnaire de paquet ?

Citation : DavGen

C'est forcément un point de vue, mais tu verras qu'à l'usage tu trouveras cela vrai toi aussi. Utilise-le pour te rendre compte à quel point c'est pratique.
Je suis totalement convaincu que c'est vraiment un des points forts du système :

- pas de recherche à faire partout sur le web, c'est centralisé
- le serveur (si tu as le bon dépôt) est rapide
- l'installation est rapide et automatique, on ne te demande pas de configurer l'application (de choisir de répertoire ou quoi) ça utilise les bons répertoires par défaut
- les dépendances sont gérées et il n'y a pas de doublon (de dll comme sous windows)
- la mise à jour de toutes les applications peut se faire en une seule commande
- les applications sont intégrées et utilisent intelligemment les ressources du système, on n'a pas de risque de conflit.

Ah j'ai hâte d'aller le consulter

Citation : Linktim

Pour le développeur, c'est plus compliqué de faire un paquet pour chaque distro qu'un setup Windows...

1337833K : moi non, puisque je gère mes dépendances moi-même.

Mais ce que je voulais surtout dire, c'est que fondamentalement, c'est justement le principe des paquetages qui introduit la notion de dépendances.

Regarde sous Windows : exception faite de quelques bibliothèques majeures (dont l'exemple typique est DirectX), la notion de dépendances n'existe pas. La plupart du temps, quand un programme a besoin d'une bibliothèque particulière, il l'installe en même temps que lui-même :
- soit dans son propre répertoire (ce qui évite d'écraser une autre version de la bibliothèque, mais du coup on peut se retrouver avec un exemplaire de la bibliothèque pour chaque programme l'utilisant, réduisant grandement l'intérêt des bibliothèques partagées) ;
- soit dans un répertoire système comme C:\Windows\System32, au risque d'écraser une autre version (éventuellement plus récente) de la bibliothèque (qui a dit "DLL Hell" ? )

Les systèmes de paquetages suppriment ces problèmes en posant comme principe qu'une bibliothèque est empaquetée dans son propre paquetage, et que les logiciels l'utilisant doivent se reposer sur ce paquetage au lieu d'amener leur propre version de la bibliothèque. Ce faisant, de façon inévitable, ils introduisent un autre problème, celui de la gestion des dépendances entre paquetages.

J'insiste sur ce point : c'est un problème inhérent aux systèmes de paquetages (aussi bien binaires que sources).

Le problème peut éventuellement être masqué (avec plus ou moins de succès) à l'utilisateur par des systèmes de résolution automatique des dépendances, mais il n'en reste pas moins présent.

[edit]Et puis, sans même passer par ce raisonnement, il suffit de se dire que si on a développé des systèmes de "gestion automatique des dépendances", c'est bien parce qu'il y a à la base un problème de dépendances à gérer...[/edit]

@mateo21,
Comptes-tu faire un tuto sur comment créer un 'setup' linux comme pour windows avec inno setup ?

Aussi, une question qui m'embète depuis un certain temps, quel est le réel intérêt du registre Windows ? Car si on n'a le 'courage' d'aller bidouiller \Program Files\, le registre c'est pas bien plus dur (mais par contre c'est crade)

Citation : smilz
http://autopackage.org/devel-zone.html

Citation : gouttegd
Ce problème n'est pas un désavantage, puisque ça permet d'économiser de la place (pas de doublons de DLL) et d'éviter de risquer un DLL Hell.

Citation : 1337833K

Bah, quand on a des problèmes de dépendances aussi des fois c'est gonflant (bidule nécessite libmachin >=2.0.19 mais ne sera pas installé)...

@ 1337833K : ne me fais pas dire ce que je n'ai pas dit, les systèmes de paquetages sont toujours mieux que ce dont disposent les Windowsiens.

Sous Linux, je j'ai jamais entendu parler d'un quelconque ".so Hell"

Mais dire que les systèmes de paquetages suppriment les problèmes de dépendances est un contre-sens.

Très bon tuto (comme d'habitude )

Personnellement j'utilise tout le temps (ou presque) apt-get. J'utilise tellement la console durant mes TP que ça deviens une habitude.

Par contre, j'avais pas fait gaffe pour les multiples serveurs, ça servira probablement pour la nouvelle version qui sort très bientôt .

Vivement le prochain tuto !

Citation : gouttegd

A ce propos, c'etait un argument fort (et ca l'est toujours) de la plateforme .Net . Avec le stockage "cote à cote" et le versionning des assemblies plus de DLL Hell ! Ceci dit de ma courte experience de Linux, il est clair que somme toute le systeme de Linux (apt et consorts) reste quand même bien pratique une fois apprivoiser (notamment par l'aspect centralisé du bouzin).

Merci de la news

@ SirJulio : je le sais bien mais bon, à l'heure actuelle, je pense que la majorité des applications Windows restent des applications "traditionnelles" (dans le sens "non .NET"), et donc restent potentiellement sujettes au "DLL Hell".

Et je ne sais pas trop si ça va réellement changer : OK, Microsoft pousse dans le sens du développement basé sur .NET (.NET 3.5, Microsoft Presentation Framework, Workflow Foundation, et tous ces trucs qui me dépassent ), mais les éditeurs tiers --- qui fournissent le plus gros des applications Windows --- sont-ils prêts à jouer le jeu ?

(C'est une vraie question, pas de la rhétorique.)

C'est un peu comme le système Microsoft Installer (MSI), censé faciliter la gestion des installations/désinstallations/mises à jours : c'est sans doute très bien, mais quand j'étais encore sous Windows je n'avais pas l'impression que c'était très utilisé (en dehors bien sûr des programmes made-in Microsoft).

Autopackage n'est qu'un gestionnaire de package de plus.

En aucun cas le développeur à besoin de fournir des packages pour chaque distribution, la seule contrainte c'est d'avoir un makefile fonctionnel (qui peut être généré par un configure).

Et bien dit donc sa fuse en ce moment les tutoriel !

Citation : Natim

En effet. Généralement si le logiciel est bon, la communauté a de bons mainteneurs de paquets prêts à le créer pour sa distribution de manière propre et homogène. Car quand on voit certains RPM fait par le créateur, ça fou le boxon ailleurs donc vaut mieux laisser la communauté faire son boulot parfois.

Citation : gouttegd
Sans vouloir troller, le gros point faible du MSI est d'être un format proprio et pas documenté, à part Microsoft et InstallShield (et encore, pas sur), personne ne pouvait donc en créer. Sinon, ça aurait été vraiment bien, et on aurait eu quelque chose d'uniforme et pratique.

@ 1337833K : oui, c'est bien dans le sens de ce que je disais : Microsoft peut bien développer tous les trucs intéressants qu'il veut (.NET, MSI, PowerShell, etc.), si les éditeurs d'applications Windows ne veulent/peuvent en tenir compte, ça ne servira pas à grand'chose.

Par exemple, beaucoup d'éditeurs semblent n'avoir toujours pas compris qu'en passant de Windows 9x à Windows 2000/XP, on est passé à un système multi-utilisateur, et ils continuent à sortir des applications nécessitant des droits administrateurs pour fonctionner...

Enfin bon, les problèmes du monde Windows n'ont pas grand-chose à faire sur cette news.

@Gouttegd :

Pour le moment, il est clair que .Net reste un peu cloisonné dans son rôle de langage "utilitaire" (secteur ou il excelle soit dit au passage). A la fois, car le C++/CLI est une horreur (en prenant C++ comme le langage le plus courant), que quand on parle d'environnement managé les gens pensent au Java d'il y a 5 ans, et, troll à part, le fait que ce soit du made-by Microsoft n'aide vraiment pas (problème de portabilité, "d'idéologie").

Donc, c'est clair, qu'à moyen terme (~5ans), on continuera de voir des applis traditionnelles, et ce pour la plus grande partie, mais .Net apporte une solution intéressante à ce problème (et c'est justement cette notion d'assembly en général qui plait). Mais, il est evident que pour le moment, la pénétration de .Net dans les applis grand publics est mineur (comme ca, je dirais Paint.Net qui est une belle reussite, ou RSSBandit)

Faire un package pour Debian est une chose plutôt compliquée car il faut vraiment mettre la main à la pate et suivre http://www.debian.org/doc/manuals/maint-guide/

Et c'est justement les paquets qui sont bien faits qui me font aimer ce système.

Par exemple ecrire un ebuild pour Gentoo ou un PKGBUILD pour Archlinux est vraiment beaucoup plus simple que de packager pour debian. Mais evidement après c'est moins propre.
Debian c'est le culte de l'excellence.

Citation : philux31

C'est pas parce que c'est plus compliqué que c'est forcément moins propre

Non, dans ce cas là c'est le contraire (enfin si on oublie ce qui est je pense une faute d'inattention, tu voulais surement mettre plus propre)

C'est parce que c'est plus propre que c'est plus compliqué.

Non pas forcément.
Les packets Zenwalk, Archlinux et Gentoo sont tout aussi propre que les packets Debian.

Ah, peut-être. J'avoue que je ne connais pas trop, mais il me semblait que Debian était réputé comme ayant le système de paquets le plus propre.

Oui, enfin, entre une réputation et la réalité, il peut y avoir une marge, hein...

Une marge qui sera d'autant plus grande si tout le monde propage la réputation en la tenant pour justifiée de fait.

(Je n'en dirais pas plus, sinon je vais me remettre à troller sur Debian. )

Heu, euh viens de faire un tracert sur fr.archive.ubuntu.com et je suis retombé sur... ftp.oleane.net !
Je suis chez Orange, alors peut-être qu'ils ont modifiés le DNS par défaut pour que l'on utilise plutôt que les serveurs officiels, mais ça m'étonnerai qu'un FAI détourne des DNS sans prévenir...
Pour ceux qui ne me croient pas, j'ai fait un nslookup.

Code : Console

Edit : bug sur le zCode . Je retire la balise code...