Dans un message à des listes de diffusion pkgsrc et NetBSD, Alistair Crooks a annoncé la disponibilité de la branche pkgsrc-2014Q4. Pkgsrc (prononcer package source) est une infrastructure de construction de logiciels tiers pour NetBSD, ainsi que pour d’autres systèmes de type UNIX. Il permet donc à NetBSD et à d’autres systèmes d’exploitation de disposer de nombreux logiciels sous forme source, mais aussi sous forme binaire.
Les développeurs pkgsrc fournissent une nouvelle version stable chaque trimestre. Comme son nom l’indique, pkgsrc 2014Q4 est donc la dernière sur les quatre de l'année 2014 et est disponible depuis le 2 janvier dernier.
Plus de détails sur cette version en particulier en seconde partie de dépêche, qui reprend grandement le courriel d'annonce.
Si vous ne connaissez toujours pas pkgsrc
À force de publier des dépêches sur le sujet (suivez le tag pkgsrc), espérons que vous commencez à connaître la chanson : pkgsrc, c'est le système de paquets logiciels pour NetBSD, issu d'un fork en 1997 de celui de FreeBSD. Nos amis au drapeau orange étant adeptes de la portabilité, il est logique que leur système de paquets puisse fonctionner ailleurs et compte toujours sa vingtaine de plateformes compatibles, allant des systèmes BSD à Windows (grâce à Cygwin/Interix/Services For Unix) en passant par GNU/Linux, OS X et Solaris.
Pour être plus concret sur la portabilité de pkgsrc, certaines personnes maintiennent des dépôts de paquets binaires en dehors de ceux pour NetBSD. Ainsi, le dépôt de la société Joyent contient des ensembles de paquets pour SmartOS, GNU/Linux mais aussi OS X. Saluons aussi le projet Save OS X, qui en plus de fournir un dépôt pour x86_64 (celui de Joyent est pour i386), propose articles et courtes vidéos introduisant pkgsrc pour le système à la pomme.
Enfin, ces initiatives ne sauraient être couronnées de succès sans pkgin, gestionnaire de paquets maintenu par iMil et dont la version 0.7.0 devrait voir le jour sous peu.
Les chiffres du trimestre
En termes de paquets, pkgsrc-2014Q4 c’est (entre parenthèses la différence avec pkgsrc-2014Q3 lorsque le chiffre était indiqué) :
- 15510 paquets possibles (+ 324) ;
- 15049 paquets binaires compilés avec clang pour NetBSD-current/x86_64 (+ 308) ;
- 12972 13026 paquets binaires compilés avec gcc pour SmartOS/x86_64 (- 54) ;
- 14430 paquets binaires compilés avec gcc pour NetBSD-6.0/x86_64.
Ce trimestre, en termes de modifications, il y a eu :
- 156 paquets ajoutés ;
- 48 paquets retirés, dont 9 avec un successeur ;
- 1575 paquets mis à jour ;
- 4 paquets ont été renommés.
Les changements
Parmi les ajouts ou mises à jour notables, on peut remarquer :
- une amélioration des paquets Haskell ;
- des mises à jour dans les paquets d'émulation Linux, basés sur SUSE 12.1 ;
- ainsi que de nombreuses bibliothèques Python, Perl, Haskell et Ruby.
La campagne de nettoyage qui a lieu chaque trimestre permet de supprimer ce qui obsolète, ou non utilisé. Cette fois-ci, c'est au tour de libreoffice3, skype1 et skype21.
Au-delà des paquets en eux-même, l'infrastructure de pkgsrc évolue. Ce trimestre, une nouvelle variable fait son apparition : PKGSRC_KEEP_BIN_PKGS (à placer dans son fichier mk.conf). Elle permet de conserver les paquets binaires de ce qui est compilé.
Un commentaire de la dépêche précédente signalait le travail de Jonathan Perkin sur l'amélioration du temps de compilation de tous les paquets de pkgsrc (ce qu'on appelle des bulk build, ou pbulk, du nom de l'outil). Alistair Crooks mentionne que l'intégration des cwrappers (qui permet cette amélioration) a progressé, et que d'autres progrès sont à attendre pour le trimestre prochain.
Alistair Crooks profite de son courriel d'annonce pour faire le bilan, non seulement de l'année 2014, mais aussi depuis 1997. Sur ces 17 années de publication de pkgsrc, 2014 se situe en troisième position en terme de nombre de changements apportés. L'année la plus faste est 2013, suivie par 2004.
Un coup d'oeil à NetBSD
La dernière dépêche traitant de nouvelles versions de NetBSD abordait les versions 6.1.5 et 6.0.6. Quelques semaines plus tard, les mêmes corrections étaient portées sur la branche 5, permettant de publier NetBSD 5.1.5 et 5.2.3. Toutefois, l'attente continue concernant NetBSD 7 : la branche existe depuis plusieurs mois dans CVS, mais est toujours au stade de beta. Si vous le souhaitez, vous pouvez télécharger et installer une de ces versions pour améliorer la future version 7 stable.
Enfin, sur une note plus personnelle, votre serviteur est maintenant lui aussi développeur NetBSD, et espère ainsi agrandir la liste des mises à jour de pkgsrc que vous pourrez lire chaque trimestre.
Aller plus loin
- pkgsrc (59 clics)
- NetBSD (38 clics)
- NetBSDfr (73 clics)
- Annonce de pkgsrc-2014Q4 sur la liste pkgsrc-users (23 clics)
- DLFP : pkgsrc 2014Q3 est disponible (23 clics)
- pkgsrc sur Wikipédia (19 clics)
- pkgsrc.se (17 clics)
- pkgsrc-wip sur Sourceforge (12 clics)
- DLFP : NetBSD 6.1.5 et 6.0.6 (22 clics)
# Et un standard de plus
Posté par Sébastien Douche . Évalué à -1.
"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. 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à.
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.
--
Seb, qui rêve parfois.
[^] # Re: Et un standard de plus
Posté par tallion . Évalué à -1.
Quand on parle de fusionner les standards, ça me fait penser à ça
[^] # Re: Et un standard de plus
Posté par barmic . Évalué à 9.
Il n'y avait pas plus de standards avant qu'après. Ce n'est pas parce que tu utilise dpkg que ça fonctionne sur toutes les distributions dérivées de debian (de même pour ebuild ou rpm par exemple).
Tu connais combien de gestionnaires de paquets qui sont supportés sur linux, *BSD, Solaris et windows ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et un standard de plus
Posté par Sébastien Douche . Évalué à -1.
Certes mais avoir le même outil donne plus de chance d'y arriver.
[^] # Re: Et un standard de plus
Posté par totof2000 . Évalué à 3. Dernière modification le 19 janvier 2015 à 15:20.
:)
Avec un tournevis, je suis capable d'enfoncer un clou. Mais un jour quelqu'un a décidé de créer un marteau parce qu'il ne trouvait pas le tournevis suffisamment adapté . Pas la peine : si tout le monde utilisait un tournevis pour enfoncer un clou, on aurait plus de chance d'y arriver …
[^] # Re: Et un standard de plus
Posté par xcomcmdr . Évalué à -2.
What a douche !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Et un standard de plus
Posté par totof2000 . É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.
[^] # Re: Et un standard de plus
Posté par Enj0lras . Évalué à 4.
Il y a des initiatives en ce sens. Par exemple, les paquets haskell sous freebsd sont automatiquement générés depuis l'équivalent de pip pour haskell :
https://github.com/freebsd-haskell/hsporter
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.