"Comme on n'aimait pas celui de Free, on a inventé un nouveau packaging." Maintenant, on a un standard de plus, que bien evidemment pas beaucoup de monde n'utilise.
Troll !!!! Avant tout pkgsrc est le système de gestion de paquets par défaut sous NetBSD. Donc tous ceux qui utilisent NetBSD utilisent pkgsrc (tout comme les utilisateurs de RedHat utilisent Yum/rpm ou les utilisateurs de Debian utilisent deb/apt).
Je voudrais bien savoir combien de gens font exactement le même taff, c'est à dire de packager exactement les mêmes applis. La diversité à du bon, mais là.
C'est plutôt après de Suse, Mandriva et RedHat que tu devrais adresser cette remarque : ils utilisent tous les trois RPM, mais ne sont pas fichus de livrer des paquets qui s'installent indifféremment sur l'une ou l'autre des distributions : à quelques excceptions près peut-être, je ne peux installer un RPM prévu pour Suse sur une Redhat/Centos. Et je ne suis pas sur de pouvoir générer un paquet Mandriva en utilisant la même configuration que celle qui m'a permis de générer un paquet RedHAt ou Suse.
L'avantage de PKGSRC est que tu inverses la tendance : peut-être qu'un paquet produit pour une Suse ne s'installera pas sur RedHAt, par contre tu n'auras pas à générer 4 "modèles" différents pour chaque distribution : tu recompiles pkgsrc pour la plate-forme qui t'intéresse et tu l'installes de la même façon partout : on n'en est pas à un gestionnaire de paquets universel, mais à mon avis c'est la solution qui s'en rapproche le plus aujourd'hui ( bien pratique sur une slackware par exemple).
Sachant qu'il existe des millions de dépôt Git et seulement quelques milliers de packages par distribution. Ce qui fait que j'utilise pip pour Python, Gem pour Ruby, etc, en plus du packaging natif. Fusionner les trucs sans «valeur ajoutée», ça serait quand même pas mal.
Je suis malhereusement obligé de te rejoindre dessus : le problème n'est pas forcément l'existence de touis ces gestionnaires, mais le besoin de les interfacer avec un gestionnaire de paquets : je ne comprends pas pourquoi par exemple, gem de Ruby ou pip de python ne pourrait pas s'interfacer avec rpm/yum, pkgsrc, ou autre.
[^] # Re: Et un standard de plus
Posté par totof2000 . En réponse à la dépêche pkgsrc 2014Q4 est disponible. Évalué à 5.
Troll !!!! Avant tout pkgsrc est le système de gestion de paquets par défaut sous NetBSD. Donc tous ceux qui utilisent NetBSD utilisent pkgsrc (tout comme les utilisateurs de RedHat utilisent Yum/rpm ou les utilisateurs de Debian utilisent deb/apt).
C'est plutôt après de Suse, Mandriva et RedHat que tu devrais adresser cette remarque : ils utilisent tous les trois RPM, mais ne sont pas fichus de livrer des paquets qui s'installent indifféremment sur l'une ou l'autre des distributions : à quelques excceptions près peut-être, je ne peux installer un RPM prévu pour Suse sur une Redhat/Centos. Et je ne suis pas sur de pouvoir générer un paquet Mandriva en utilisant la même configuration que celle qui m'a permis de générer un paquet RedHAt ou Suse.
L'avantage de PKGSRC est que tu inverses la tendance : peut-être qu'un paquet produit pour une Suse ne s'installera pas sur RedHAt, par contre tu n'auras pas à générer 4 "modèles" différents pour chaque distribution : tu recompiles pkgsrc pour la plate-forme qui t'intéresse et tu l'installes de la même façon partout : on n'en est pas à un gestionnaire de paquets universel, mais à mon avis c'est la solution qui s'en rapproche le plus aujourd'hui ( bien pratique sur une slackware par exemple).
Je suis malhereusement obligé de te rejoindre dessus : le problème n'est pas forcément l'existence de touis ces gestionnaires, mais le besoin de les interfacer avec un gestionnaire de paquets : je ne comprends pas pourquoi par exemple, gem de Ruby ou pip de python ne pourrait pas s'interfacer avec rpm/yum, pkgsrc, ou autre.