Ce que psn00ps dit, c’est que ça permet d’installer Firefox pour soi, sans avoir les droits admin/sans impacter les autres utilisateurs.



C’est une critique acceptable de Linux (hélas) : On ne peut pas installer un logiciel “pour soi” sans avoir les droits admin, ni le mettre à jour.

C’est faisable certes, mais pas les paquets précompilés qui contiennent des références à /usr/lib et /usr/share.

Et ce n’est pas la façon de faire habituelle, ce n’est pas user-friendly de le faire :)

Après, ya les paquets xdg-apps/snappy(beurk)/Appimage qui commencent à arriver et qui changeront peut-être ça. Mais on pert un peu de l’“essence” de la gestion des paquets et des librairies partagées sous Linux qui est clairement un avantage !

C’est ce que je disais : la nécessité des droits root est une critique acceptable de Linux, dans le sens où c’est un vrai problème.

Après ça a de vrais avantages, mais peu pour un ordinateur personnel (avec un seul utilisateur). D’où l’existence de sudo.



Pour les librairies et les dépendances, je suis à moitié d’accord avec toi.

En effet, ça impose un travail d’intégration à chaque distrib.

Mais si le développeur est clair sur les besoin de son logiciel (simple liste des dépendances + système de build transparent (c’est déjà le cas) + “comment dire au système de build les chemins vers les libs et include” (c’est peut-être là qu’il faut un peu de boulot, mais pas tant que ça si tu utilises les systèmes de build classiques (autotools, cmake, etc))), le seul travail à faire est du côté du mainteneur de la distrib, et ce n’est pas compliqué.

Exemple, j’ai écrit quelques PKGBUILDs pour ArchLinux, dans le pire des cas j’ai pris 20 minutes à écrire le paquet + tout vérifier.

Uther a écrit :

Un rpm sur Fedora, plus un deb pour Debian, qui sera peut être ou peut-être pas compatible avec Ubuntu, et je ne parle même pas des distribution plus rares ou des problèmes si on veut plusieurs versions d’un même logiciel. Un développeur ne peut pas gérer toutes les distributions.



Certes tant que l’on reste dans les paquets officiels de sa distribution tout va bien, mais une distribution ne peut pas non plus maintenir a jour le packaging de tous les logiciels existants.  

 Justement, un développeur ne se soucie à peu près jamais de la destribution et du packaging de son logiciel. Tu fais ton code, dans ton Readme tu dis “faites ./configure && make pour compiler avec comme argument le chemin vers le dossier de librairies et le dossier de données (souvent /usr/share/le_logiciel)” et basta.

 

Après, c’est bien gentil de dire que “ya plein de distros c’est chiant” mais au fond, elles sont organisées pareil. /usr/bin, /etc pour la config, /usr/share pour les données. Et avec autotools, make install te fait direct l’arborescence de ton logiciel.

Du coup, la création de paquets revient quasi uniquement (d’expérience) à rattraper les erreurs des développeurs.



La seule incompatibilité entre Ubuntu et Debian (comme tu l’as noté) n’est pas due aux paquets eux-mêmes. Elle est due aux imbéciles de maintencurs d’Ubuntu qui ont cru intelligent de prendre le même format de paquets, à peu près les mêmes bases de données, mais EN CHANGEANT LE NOM DES PAQUETS DE LIBRAIRIES. Du coup un paquet Debian ne retrouve plus ses petits. Bon et aussi au fait que Apt-Get, c’est en carton pas solide.

+1

Et oui le développeur fait rarement du packaging, à part pour des raisons de tests.

 Et si le packaging du logiciel est trop compliqué, c’est certainement qu’il est mal développé (gros yeux vers QtiPlot, bordel…).

C’est pour ça que quand je vois des projets qui embarquent leurs dépendances dans leur code source, je pète un câble. Oui ça fait un peu de boulot en plus pour vérifier que ça tourne avec la nouvelle version de la lib, mais tout le monde en profitera. Et le fait qu’il y ait une floppée de distributions n’y change rien. Tu vis dans un écosystème avec plein de projets, plein de librairies, faut faire avec.