pkgsrc 2013Q2 est disponible

Posté par  (site web personnel, Mastodon) . Édité par Benoît Sibaud, claudex et GeneralZod. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
25
8
juil.
2013
NetBSD

L'équipe de pkgsrc est fière de vous annoncer la disponibilité de la branche pkgsrc-2013Q2 ! Pkgsrc est un framework 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 2013Q2 est donc la deuxième sur les quatre prévues en 2013, et est disponible depuis le 4 juillet.

Plus de détails sur cette version en particulier en deuxième partie de dépêche.

À propos de pkgsrc

Pkgsrc est historiquement le système de paquets pour NetBSD, issu d'un fork en 1997 de la collection de ports FreeBSD. Avec le temps, pkgsrc a évolué, et dans le même esprit de portabilité que NetBSD, est utilisable sur plusieurs systèmes d'exploitation. Ils peuvent alors gérer leur propre collection de paquets sources et binaires. Ainsi, pkgsrc prend en charge une vingtaine de plateformes, dont voici un extrait :

  • Cygwin ;
  • Darwin/Mac OS X ;
  • DragonFly ;
  • FreeBSD ;
  • Interix/SFU/SUA ;
  • Linux ;
  • Minix3 ;
  • NetBSD ;
  • OpenBSD ;
  • Solaris/illumos.

Quelques chiffres

En terme de paquets, pkgsrc-2013Q2 c'est :

  • 12389 paquets au total pour NetBSD-current/amd64 ;
  • 11912 paquets binaires compilés avec gcc pour NetBSD-6.1/amd64 ;
  • 11906 paquets binaires compilés avec clang pour NetBSD-current/amd64 ;
  • 10254 paquets binaires compilés avec gcc pour SmartOS/i386.

Ce trimestre, en terme de modifications, c'est :

  • 318 paquets ajoutés ;
  • 41 paquets renommés ;
  • 32 paquets retirés ;
  • 1564 paquets mis à jour.

Les nouveautés

Dans les ajouts et mises à jour, il y a une avalanche de dictionnaires pour aspell et ispell, ainsi que plus de 50 localisations pour KDE4. Toujours pour KDE4, plusieurs jeux et applications multimédias se sont retrouvés dans leur propre paquet. On peut aussi noter l'apparition de node.js. Les paquets gcc-4.8, opencobol, X11 et Mesa sont aussi mis à jour.

Du côté des retraits de paquets, ce sont principalement postgresql-8.3, xulrunner, clutter08 et ruby-clutter qui tirent leur révérence. Python-3.1 a été remplacé par python-3.3. Notons aussi la disparition de bind-9.7.

À chaque nouvelle version de pkgsrc, deux développeurs nominent un ou plusieurs paquets « Package of the Quarter ». Cela permet de mettre en avant certains logiciels utiles mais méconnus, ou de souligner l'important travail effectué pour les empaqueter. Ainsi, John Nemeth a nominé xenkernel42 et xentools42, qui apportent Xen 4.2 à NetBSD. Quant à Alistair Crooks, il a nominé jq, en tant que « merveilleux moyen d'interpréter et d'afficher du JSON ».

pkgsrc-wip

Vous avez peut-être envie de contribuer à pkgsrc ? C'est plus facile qu'on ne le croit, et cela passe par pkgsrc-wip : il s'agit d'un projet hébergé sur Sourceforge, et chapeauté par Thomas Klausner. Le principe est le suivant : vous créez un compte Sourceforge, vous demandez gentiment à Thomas de vous ajouter comme développeur pour pkgsrc-wip, et vous pouvez contribuer vos paquets. Une fois qu'ils sont prêts, vous pouvez demander une relecture (« review request » sur une liste de diffusion prévue à cet effet). Une fois la relecture passée, vous pouvez effectuer une demande d'import dans pkgsrc via Gnats, l'outil de gestion des bogues de NetBSD.

Contrairement à pkgsrc, pkgsrc-wip ne dispose pas de version numérotée, et aucun dépôt de paquets binaires n'est officiellement disponible, même pour NetBSD.

Aller plus loin

  • # DragonFly -> DPorts ?

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Il semble que DragonFlyBSD s’oriente plutôt vers DPorts (et donc pkgng), qui est plus proche des ports de FreeBSD. Mais je n’ai pas suivi les détails. Quelqu’un pour en dire plus ?

    • [^] # Re: DragonFly -> DPorts ?

      Posté par  (site web personnel) . Évalué à 4.

      Le système de pkg officiel de DragonflyBSD reste pour l'instant pkgsrc. Dports est un hack des ports FreeBSD pour que ça fonctionne sur DragonFlyBSD. L'intérêt principal est, d'après ce que j'ai compris, de pouvoir utiliser les outils de gestion des paquets binaires pkgng, qui semblent être meilleurs que ceux offerts par pkgsrc (pkgin entre autre), en particulier pour la mise à jour du système. Difficile à dire comment ça va évoluer, ça dépendra de combien de développeurs vont contribuer à dports et quelles parties vont être remontées dans le système de ports officiels de FreeBSD. Mon avis personnel est que le jeu n'en vaut pas la chandelle, et qu'il aurait mieux valu améliorer les outils de gestions binaires de pkgsrc. M'enfin, c'est la beauté du libre :D

      • [^] # Re: DragonFly -> DPorts ?

        Posté par  . Évalué à 4. Dernière modification le 09 juillet 2013 à 19:13.

        Ton mot hack sonne assez péjoratif. Le fait est que c'est simplement git et des scripts qui permettent de merger les différences. C'est plus un overlay avec des patchs qu'un "hack". Au fond, c'est juste une approche différente.

        DISCLAIMER : je ne parle pas de pkgsrc en général ni même de pkgsrc sur dragonfly mais uniquement de ma propre expérience des paquets tiers sur un système dragonfly.

        L'impression que j'ai en tant qu'utilisateur, c'est que pkgsrc est plus propre niveau portabilité, mais cette propreté rend les choses aussi plus lourdes à maintenir. La propreté, le beau code, tout ça c'est très bien. Mais en pratique, on veut aussi des choses qui marchent. Et mon expérience montre que dports fonctionne indéniablement mieux sur DragonflyBSD que pkgsrc au niveau des paquets binaires. En fait, je dirais même qu'ils passent du stade "prétexte : des paquets binaires sont disponibles et on peut le mettre sur la liste de feature et installer firefox/2-3 gros logiciels" au stade "utilisable en pratique". Il ne faut pas se leurrer, les paquets binaires pkgsrc pour dragonfly ont beau exister, j'ai toujours été confronté à milles petits problèmes qui rendent la vie de l'utilisateur compliquée. D'ailleurs, je ne dois pas être le seul de cet avis quand on regarde les statistiques de téléchargement des paquets binaires de pkgsrc postés sur la ML.

        Je trouve que du point de vue utilisateur, ma vie est plus simple avec dports/pkgng. Je peux faire pkg upgrade régulièrement sans que rien ne casse, j'ai des paquets à jour, tout les paquets que j'utilise sont disponibles. En bref, tout fonctionne. Alors, le code est peut être moins joli, moins portable, etc mais personnellement, je m'en fou. Au vu des ressources en développeur, réutiliser les bons outils de freeBSD me parait une bonne idée, et c'est pour ça que je trouve que au contraire, le jeu en valait la chandelle.

        • [^] # Re: DragonFly -> DPorts ?

          Posté par  (site web personnel) . Évalué à 2.

          Hack ce n'est pas en soit péjoratif, sale hack par contre :). Bref, j'ai l'impression que c'est assez coûteux à maintenir comme système, vu que les patchs ne rentrent à priori pas dans ports. Je ne sais pas précisément comment se fait la synchronisation des sources entre ports et dports, mais je pense que sur le long terme, ça risque d'être pénible, c'est dans ce sens que je pense que ça me parait une méthode coûteuse (en temps, en homme). D'autant plus qu'un certains nombres de développeurs DragonFly se sont investis dans pkgsrc. Après, ce ne sont évidemment pas des compétences perdues.

          Après, comme je le disais, du point de vue de la gestion des binaires, pkgng est probablement largement supérieur. pkgsrc, y'a src dedans :) et la question des binaires est toujours problématiques même sur NetBSD. pkgin semblerait être une solution à ce genre de problèmes, je ne l'ai pas assez utilisé pour avoir une opinion fondée sur la question.

          • [^] # Re: DragonFly -> DPorts ?

            Posté par  (site web personnel) . Évalué à 5.

            DPorts est beaucoup plus simple a maintenir pour les gens de Dragonfly que pkgsrc, et les outils autours des ports permettent un très grande simplicité. Pour info, l'auteur de dports a maintenant un commit bit dans les ports FreeBSD, ce qui devrait grandement faciliter les choses.

            Parmis les motivations qui a poussé DPorts il y a justement la facilité du portage, DragonFly reste relativement proche de FreeBSD, il n'y a donc pas grand chose a faire pour qu'un ports FreeBSD compile correctement et tourne sous DragonFly, il suffit de rajouter à cela poudriere et pkgng et la différence pour les gens de DragonFly est énorme.

            Pour info poudriere c'est une sorte de 'pbulk' mais extrêment performant, et hautement parallélisé (a tel point qu'il a mit en avant énormément de bug DragonFly - kernel, fs, tty, réseau, etc - qu'il a fallut corriger pour pouvoir faire tourner une construction de package complète aka tout le ports tree sans cracher l'os) Cet outil permet très rapidement sur une machine un peu costaud de construire tous l'arbre des ports.

            Le résultat a été qu'ils ont pu bénéficier de plus de 20k packages en quelques mois de boulot d'un seul mec ! Chose que ce même gars n'a pas pu obtenir avec pkgsrc. En ce qui concerne les aller et retours, les ports FreeBSD bénéficient déjà de retour venant de dragonfly: bug fix et idée issues de l'expérience de l'auteur en question sur pkgsrc.

            En ce qui concerne pkgng, ça leur a permit d'avoir un outil qui fait la gestion complète des packages binaries sur dragonfly, l'adoption par les utilisateurs de DFly n'a pas tardé.

            Les statistiques sont assez flagrante et une très grosse partie (je pense la grande majorité) des utilisateurs de DragonFly sont passés a dports+pkgng.

            Bref c'est surtout parce que justement il est plus simple de maintenir d'un point de vue humain dports que pkgsrc sous dfly que le switch a eu lieu.

            Pour info l'auteur de dports continue a travailler sur pkgsrc et aime toujours pkgsrc :), il envisage même de pouvoir générer des packages pkgng avec pkgsrc, en tout cas il se pose la question de la faisabilité.

            • [^] # Re: DragonFly -> DPorts ?

              Posté par  (site web personnel) . Évalué à 2.

              Un bon logiciel (pas trop linux centric) devrait compilé sur toute plateforme relativement unix, avec un Makefile minimum, port ou pkgsrc. Le problème sous-jacent, c'est imho la portabilité des logiciels.

              Mon interrogation concernait surtout la méthode de synchronisation entre ports et dports. Par exemple, firefox est rentré dans ports il y'a deux semaines, mais n'est pas encore dans dports. Une synchronisation semi-manuelle entre les deux dépôts me parait extrêmement coûteuse en temps (et extrêmement rébarbatif aussi), surtout pour quelques hommes. De plus, en regardant rapidement le dépôt github de dports, je vois beaucoup de 'tweaks xxx', ce qui me laisse penser qu'il y'a quand même une certaine adaptation à faire.

              Concernant poudriere, vu que je vois que tu as travaillé dessus, est-ce que tu peux me dire qu'est qu'il fait qu'il est beaucoup plus performant qu'un pbulk ? Est-ce que ça serait dur de le porter à pkgsrc ou au contraire est-ce que ça utilise des features extrêmement spécialisés de ports ?

              • [^] # Re: DragonFly -> DPorts ?

                Posté par  (site web personnel) . Évalué à 6. Dernière modification le 10 juillet 2013 à 22:37.

                Un bon logiciel (pas trop linux centric) devrait compilé sur toute plateforme relativement unix, avec un Makefile minimum, port ou pkgsrc. Le problème sous-jacent, c'est imho la portabilité des logiciels.

                J'aime la théorie, la pratique est très loin de là.

                Mon interrogation concernait surtout la méthode de synchronisation entre ports et dports. Par exemple, firefox est rentré dans ports il y'a deux semaines, mais n'est pas encore dans dports. Une synchronisation semi-manuelle entre les deux dépôts me parait extrêmement coûteuse en temps (et extrêmement rébarbatif aussi), surtout pour quelques hommes. De plus, en regardant rapidement le dépôt github de dports, je vois beaucoup de 'tweaks xxx', ce qui me laisse penser qu'il y'a quand même une certaine adaptation à faire.

                C'est la même chose qu'avec pkgsrc ici, quand une mise a jour entre dans pkgsrc, elle ne passait pas non plus forcément sous dfly, donc le problème est identique. de plus dports fonctionne avec un système de as, seuls les ports ayant passé ce sas sont synchronisés, aka, seul ceux qui sont passer a travers une machines de build en cleanroom (poudriere) avec succès sont synchonisés, c'est pour ça qu'il y a 2 git dans dports.

                Concernant poudriere, vu que je vois que tu as travaillé dessus, est-ce que tu peux me dire qu'est qu'il fait qu'il est beaucoup plus performant qu'un pbulk ? Est-ce que ça serait dur de le porter à pkgsrc ou au contraire est-ce que ça utilise des features extrêmement spécialisés de ports ?

                Oui je peux le dire, par exemple sur une machine avec 24 core et 100G de ram je suis capable de compiler l'intégralité du ports tree en 18h chose qui est totallement impossible avec pbulk.
                Par défault si tu as 24 coeurs alors tu auras en permanence 24 packages qui compile en parallèle, le code a été vraiment travailler pour la performance (oui c'est possible en pure shell posix).

                Je suis l'auteur de poudriere (et de pkgng) , donc si quelqu'un veut porter poudriere pour pkgsrc, c'est avec plaisir que je lui fournirai l'accès au répo fossil ainsi que les input pour le faire.

                Poudriere dispose de spécificité ports/freebsd mais facilement contournable et reste bien générique. par contre attention il stress vraiment très fort l'OS dans tous les sens (un petit peu moins violent maintenant), du coup tu risques d'avoir des surprises :), en 5min il crachait le kernel dragonfly au début du portage :), il a permit de trouver des races conditions dans l'OS absoluement partout :), sur un NetBSD j'avais fait un portage rapide il y a longtemps, et je suis tombé sur un deadlock dans le fs (corrigé depuis si j'ai bien compris) très très rapidement. Si tu arrives a le porter tu verras toi même la différence avec pbulk :)

                #poudriere (anglais) sur freenode pour en discuter si tu veux.

  • # pkgsrc, je ne sais pas.

    Posté par  . Évalué à 3. Dernière modification le 09 juillet 2013 à 14:31.

    Mais ce jq cité dans la dépêche est vraiment sexy.

    Quant à Alistair Crooks, il a nominé jq, en tant que « merveilleux moyen d'interpréter et d'afficher du JSON ».

    Le projet se dit lui même ainsi,

    jq is like sed for JSON data – you can use it to slice and filter and map and transform structured data with the same ease that sed, awk, grep and friends let you play with text.

    Pour l'exemple c'est par là,
    http://stedolan.github.io/jq/tutorial/

    Et c'est même portable…

    Maintenant, est ce vraiment totalement novateur je ne sais pas, mais mes yeux sont émerveillés.

    Merci pour cette info !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.