Nous avons la chance d'avoir quelques développeurs qui fréquentent LinuxFR.org (what else ?), dont Baptiste Daroussin (alias Bapt) qui contribue au système d'exploitation libre FreeBSD – tout comme Jean-Sébastien Pédron dont nous avons recueilli les propos il y a quelques jours : hasard ou coïncidence ? ;-)
Baptiste est quant à lui à l'origine de « pkgng », le nouveau système de packages binaires pour FreeBSD qui a été repris par DragonFly BSD.
Pour illustrer à quel point ce genre de fonctionnalité était attendu de longue date, je citerai ce que m'a confié un peu plus tôt un administrateur systèmes :
Baptiste c'est un peu notre sauveur pour l'utilisation de systèmes BSD en contexte professionnel.
pkg(8) et poudriere me font facilement gagner une à deux heures par semaine pour l'administration d'un parc de serveurs.
Baptiste a accepté de répondre à quelques questions pour LinuxFR.org ; nous le remercions chaleureusement à la fois pour le temps consacré à cet entretien et pour son implication dans FreeBSD !
À noter que certains hyperliens ont été ajoutés après coup par les contributeurs à cette dépêche pour en faciliter la lecture.
Pourrais-tu te présenter en quelques mots ?
J'ai 33 ans, je suis committer FreeBSD depuis 2010 (ports) et 2011 (sources), je suis membre de l'équipe portmgr (NDLA : The Ports Management Team) depuis 2011.
Mes contributions principales à FreeBSD sont :
- Un nouveau gestionnaire de package : pkgng
- Un nouvel outil de génération de packages : poudriere
- De la maintenance dans les sources FreeBSD.
Comment définirais‐tu ton rapport au logiciel libre, et comment es‐tu entré en contact avec lui ?
Quand je me suis acheté mon premier ordinateur, j'en ai fait le montage avec des amis, dont un utilisait Linux avec comme environnement GNOME 1 avec e16 comme window manager. J'ai trouvé ça sympa, je lui ai demandé de m'installer ça.
Je me suis retrouvé donc avec une Mandrake et un guide du rootard (NdM: remplacement par un lien archive.org) ; la Mandrake a vite été remplacée par une Slackware.
Mon premier contact FreeBSD s'est fait au sein de l'association iTeam.org lorsque j'étais à l'école.
Parlons de ton travail en cours sur pkgng, le nouveau système de packages binaires pour FreeBSD. Dans quel contexte ce projet a-t-il démarré et pourquoi un nouveau système de packages binaires ?
pkgng a démarré un peu au hasard. Tout d'abord, il n'y avait pas de vrai gestionnaire de packages binaires sous FreeBSD capable de mettre à jour les packages simplement. Je me suis donc dit que ce serait une bonne idée de porter pkgin qui en était à ses débuts à l'époque sous NetBSD. Le portage a pu être assez rapidement fait mais je n'étais pas du tout satisfait des résultats ni des performances avec 25 000 packages.
Parmi les problèmes majeurs, il y avait :
- tous les appels à
pkg_*, qui rendaient complexe le boulot de pkgin ; - la méthode, consistant en une désinstallation suivie d'une réinstallation, qui n'est pas ce que je pourrais appeler un upgrade.
Pour répondre au premier point je suis allé jeter un œil dans le code de pkg_install (bien mal m'en a pris : je déconseille fortement à n'importe qui sain d'esprit de lire ce code). Puis j'ai jeté un œil aux différents Google Summer of Code concernant la création d'une libpkg qui ont eu lieu mais dont aucun n'a abouti réellement.
Finalement vers l'été 2010 j'ai décidé que repartir from scratch était la meilleure idée : c'est comme ça en gros que pkgng est né. Julien Laffaye (jlaffaye@) a été assez fou pour me suivre dans cette idée.
Dès que l'on a pu sortir un PoC en mars 2011, j'ai envoyé un mail sur les mailing lists et on a été invité au DevSummit FreeBSD ayant lieu lors du BSDCan pour présenter ce que l'on avait pondu… pkgng a réellement démarré là.
Ensuite la version estampillée 1.0 est sortie en août 2012, la version 1.1 en juin 2013, pour le moment la version 1.2 est prévue pour décembre 2013…
Comment se situe pkgng par rapport à d'autres systèmes, notamment RPM, Deb…?
Les formats de packages comme RPM/Deb, mais aussi tous les autres, n'ont rien de vraiment intéressant… Finalement ils sont tous la même chose : une archive, des méta-données et basta.
Ce qui devient intéressant c'est l'orchestration d'une installation/mise à jour et les fonctionnalités des outils qui manipulent ces packages.
J'ai passé pas mal de temps a étudier comment fonctionnent la majeure partie des outils dpkg+apt, rpm+yum, rpm+zypp, pacman, emerge dans le monde Linux mais aussi les pkgtools d'OpenBSD, pkg sous OpenSolaris, installp sous AIX etc.
Il y a beaucoup de choses intéressantes là dedans et beaucoup de choses moins bien.
Au final les sources les plus intéressantes ont été :
- rpm + (yum ou zypp),
- dpkg + apt,
- les pkgtools d'OpenBSD.
pkgng 1.1.4 se compare pas trop mal aujourd'hui par rapport aux outils cités ci-dessus. Les choses qui manquent a pkgng pour le moment sont :
- un solveur plus intelligent (il a fait l'objet d'un Summer of Code et sera intégré dans pkg 1.2),
- une gestion plus fine et intelligente des fichiers de configuration.
pkgng se différencie de la majeure partie des autres outils de packages par :
- un front-end unique: pkg(8),
- une bibliothèque qui fait tout et a pour but de maintenir une API stable (libpkg).
Une différence notable est la simplicité pour faire des dépôts. Là dessus je pense qu'aucun projet ne fait plus simple pour construire de manière saine des packages (aka dans un environnement isolé où seules les dépendances sont installées et pas plus) jusqu'à la distribution. Avec poudriere c'est une seule commande ! Pour comparer, dans l'univers Fedora c'est un peu le pendant de Mock sauf que c'est beaucoup plus simple et que ça permet beaucoup plus de choses.
Pour information, sur un serveur de type : 24 cœurs/100 Go de RAM, poudriere peut compiler l'ensemble des 25 000 packages en 18 heures !
Une killer feature de pkgng c'est aussi le support de SSH (support finalisé dans la version 1.1.5) comme protocole de distribution de packages.
Où en est le projet à l'heure actuelle ?
Le projet en est à la version 1.1.4, et commence à rentrer en rythme de croisière – il est parfaitement utilisable au quotidien ; il est aussi beaucoup utilisé : j'ai énormément de retours de gros parcs utilisant pkgng en production.
La version 1.2 devrait apporter un nouveau SAT solver qui devrait résoudre beaucoup de problèmes et surtout apporter beaucoup d'améliorations.
Ce solveur permet de résoudre automatiquement les conflits (par exemple deux packages proposent d'installer /usr/local/bin/perl) en choisissant lequel des packages donne le plus de satisfaction, mais aussi de désinstaller les packages qui ne sont plus nécessaires ou qui sont remplacés.
Ce solveur nous permet aussi de ne plus dépendre de packages mais aussi de « provides/requires » : ainsi une application web ne dépendra plus d'Apache mais de « http server ».
Ce solveur est aussi « pluggable » ce qui permettra aux divers laboratoires de recherche sur les algorithmes de « sat solver » de pouvoir implémenter leurs recherches directement dans un plugin pkgng et les tester en direct sous la forme d'un plugin pkgng.
pkgng a été adopté par DragonFly et PC-BSD.
La majeure partie des problèmes rencontrés par pkgng sont plutôt dus à l'infrastructure de génération (les ports) plus qu'à pkgng lui-même. Beaucoup de travail à faire de ce côté là. Par exemple beaucoup de ports produisent des packages avec des noms identiques générant beaucoup de conflits et rendant moins intuitif leur installation depuis pkg – par exemple pkg install subversion vous proposera trois versions de subversions :) et n'ira pas au bout de l'installation parce que bien sûr les trois versions sont en conflit les unes avec les autres.
Pkgng souffre aussi beaucoup des compatibilités avec les vieux outils : lorsque FreeBSD arrêtera de supporter les vieux outils on pourra alors nettoyer beaucoup le code de pkgng et améliorer beaucoup de choses en interne. Aucune date n'est encore prévue pour ça. L'arbre des ports doit pouvoir fonctionner sur toutes les versions de FreeBSD supportées. Supprimer la compatibilité avec les vieux outils signifie que l'on doit forcer les installations de FreeBSD 8 et 9 a utiliser pkgng ce qui n'est pas forcément du goût de tout le monde. Ce qui est certain en revanche c'est que FreeBSD 10.0 sortira (fin 2013 ou début 2014) uniquement avec le support pkgng.
Pkgng a grandi, je reste le développeur principal, mais plusieurs développeurs actifs nous ont rejoints: Bryan Drewery (bdrewery), Matthew Seaman (matthew@), Vsevolod Stakhov (vsevolod@), et beaucoup de contributeurs (développeurs FreeBSD ou « simples utilisateurs »).
Quelles difficultés rencontres-tu ? Quelles sont les évolutions prévues ?
Les difficultés que je rencontre sont majoritairement de l'ordre de l'habitude. Beaucoup de monde a en effet l'habitude d'utiliser les vieux utilitaires et ne comprennent pas l'intérêt de passer à pkgng (jusqu'à ce qu'ils essayent pour de vrai – que ce soit en 100% binaires ou depuis les ports via portmaster et/ou portupgrade).
Une difficulté inattendue est la préparation d'une infrastructure de compilation et surtout de diffusion de packages officiels pour FreeBSD. C'est beaucoup plus complexe qu'on ne le pense. Surtout que le projet (FreeBSD) a aussi souhaité profiter de l'arrivée de pkgng pour revoir beaucoup de choses dans son infrastructure et avoir beaucoup plus de maîtrise sur les miroirs, du coup la mise a disposition de packages prend plus de temps que prévu.
Enfin il a été décidé de mettre en place une infrastructure de signature des "repository" pkgng officiels du projet, et dès que l'on touche à ce genre de choses, tout devient beaucoup plus compliqué :)
Lorsque l'arbre des ports n'aura plus besoin d'être compatible avec les anciens utilitaires, les évolutions suivantes pourront être intégrées :
- Support des provides/requires,
- Support des sub packages (oui par exemple enfin les debuginfo!).
L'on discute de plus en plus à propos de l'idée d'empaqueter base en plusieurs sous-packages dans un dépôt dédié, avec notamment la possibilité de faire les mises à jour binaires avec pkgng au lieu de freebsd-update(9) : bien que possible en théorie (certains – dont moi – le font déjà) cela nécessite quelques améliorations dans le système de compilation de base ainsi que pkgng (en particulier la gestion propre des fichiers de configuration).
Échanges‐tu avec les développeurs des autres *BSD sur ta partie ?
Les échanges sont assez nombreux, essentiellement avec DragonFly. En effet sous l'impulsion de John Marino, aidé maintenant par François Tigeot, pkgng et les ports FreeBSD ont été porté sous DragonFly avec des résultat plus que convaincants. La dernière version de DragonFly dispose du support au choix entre pkgsrc ou pkgng + ports, je suis convaincu que la prochaine version de DragonFly sortira avec uniquement pkgng.
J'ai aussi été approché par des gens de NetBSD pour générer des packages pkgng avec pkgsrc, mais aussi pour réutiliser poudrière.
Concernant OpenBSD j'ai déjà eu quelques contacts avec plusieurs développeurs mais je ne pense pas qu'ils soient intéressés par pkgng (mais je suis ouvert à toute collaboration s'ils le souhaitent), leurs pkgtools sont déjà bien avancées.
Il y a aussi des projets de portage de pkgng sous Solaris et sous Linux.
Quels sont les prochains sujets et même les futurs enjeux pour FreeBSD ?
Il y a de plus en plus de sociétés se tournant vers FreeBSD ; avoir un vrai gestionnaire de packages aide beaucoup pour ça. Depuis deux ans on sent réellement que FreeBSD est de plus en plus apprécié et utilisé. Il faut que le projet puisse mettre à disposition des packages binaires et ce de manière fiable. Permettre aussi des mises à jour de packages transparentes y compris pour les cas de mises à jour une fois tous les trois ans (un vrai casse-tête :))
En ce qui concerne plus particulièrement les packages, il va y avoir de grosses améliorations de l'arbre des ports (framework de génération de package) : celui-ci n'a jamais été vraiment prévu pour maintenir vingt cinq mille packages, ni même pensé pour produire des packages binaires… Beaucoup de travail est à prévoir de ce côté pour le rendre plus moderne.
Le plus dur c'est d'améliorer sans tout casser :)
As‐tu d’autres projets relatifs à FreeBSD ou au Libre en général ?
Je contribue de manière plus ou moins régulière à :
- pkgconf, un remplaçant (compatible) pour pkg-config.
- i3 et outils associés, un window manager tilling.
Il y a de nombreux projets pour lesquels j'ai produit des patchs, souvent pour du support FreeBSD mais des fois un peu plus, parmi lesquels: zsh, Chromium, LibreOffice, Fossil, Xorg, etc.
Je développe aussi quand j'ai le temps :
Quels distribution et environnement graphique utilises‐tu ?
J'utilise quasi exclusivement FreeBSD. CURRENT pour la plupart des cas mais j'ai aussi quelques 9.1-RELEASE. Comme environnement de bureau c'est essentiellement i3 (donc xterm, Firefox, Chromium, LibreOffice, Mutt, Irssi, vim) sauf sur mon portable où i3 est remplacé par PekWM.
Aller plus loin
- pkgng sur le wiki FreeBSD (196 clics)
- GitHub de pkgng (79 clics)
- Fossil de poudriere (101 clics)
- Blogue de Baptiste Daroussin (158 clics)
- FreeBSD Handbook, chapter 5. Installing Applications: Packages and Ports (59 clics)
- FreeBSD 9.1 est sorti - Journal de Patrick Lamaizière (187 clics)
# Est-ce fonctionnel ?
Posté par MTux . Évalué à 5. Dernière modification le 06 septembre 2013 à 16:34.
Interview super intéressante merci !
Mais depuis
trèslongtemps on ne peut pas utiliser pkgng sur FreeBSD car les dépôts sont vides. Est-ce rétabli depuis ?[^] # Re: Est-ce fonctionnel ?
Posté par Samir Noir (site web personnel) . Évalué à 2.
Il me semble que les dépôts sont pour l'instant juste fonctionnel pour pouvoir bootstrapper pkg sur le système.
Sinon, PcBSD propose un dépôt pkgng (http://wiki.pcbsd.org/index.php/Turn_FreeBSD_into_PC-BSD%C2%AE)
[^] # Re: Est-ce fonctionnel ?
Posté par François Tigeot . Évalué à 2.
Je ne sais pas ce qui fait que FreeBSD n'a toujours pas redéployé de dépôt au moins semi-officiel, mais il n'y a pas ce problème sous DragonFly, chaque architecture a un peu plus de 20,000 paquets binaires disponibles.
pkg update
pkg install zsh
pkg upgrade
etc…
fonctionnent sans problème.
Rien n'empêche également d'utiliser Poudriere et de se faire ses propres dépôts privés.
[^] # Re: Est-ce fonctionnel ?
Posté par Bapt (site web personnel) . Évalué à 6.
La raison de la non publication des repos officiels pkgng est politico-humano-bla
A savoir techniquement le projet ne veut maintenant diffuser que des repos signés, mais qui dit signature dit infrastructure de signature, politique de revocation etc et là c'est la merde :)
Donc techniquement on peut le faire mais en pratique bah…
Sinon si vous mettez:
packagesite: http://pkg-test.freebsd.org/pkg-test-${ABI} dans vos /usr/local/etc/pkg.conf vous avez des répos dispo :)
[^] # Re: Est-ce fonctionnel ?
Posté par neil . Évalué à 5.
Je suppose que c’est ce qui est indiqué dans l’interview quand il dit :
C’est à dire que
pkgbetaest vide depuis l’incident de sécurité il y a un peu moins d’un an. J’imagine que d’ici à ce que tout soit remis en place, il faut avoir son propre repository, ce qui ce fait très bien avec poudriere.[^] # Re: Est-ce fonctionnel ?
Posté par MTux . Évalué à 2.
Merci pour l'info, mais je suis vraiment déçu.
Donc en gros pkgng te facilite la vie mais tu dois déjà prendre la peine de te faire une builbox et compiler + maintenir la totalité des ports.
Ou alors utiliser les repo de PC-BSD, mais je trouve ça très sale, un peu comme si j'utilisais le repo ubuntu 12.04 dans debian wheezy…
[^] # Re: Est-ce fonctionnel ?
Posté par Loïc Blot (site web personnel) . Évalué à 6.
Personnellement, j'ai un serveur poudrière (VM avec 3 coeurs) contenant mes principaux logiciels, compilés avec les options dont j'ai besoin. Il n'est pas nécessaire de compiler tous les ports (heureusement !) Tu spécifie la liste des ports que tu veux, il s'occupe de compiler les dépendances (et te demander les options).
J'ai par exemple, apache, dovecot, postfix, puppet, nrpe… en gros une liste d'une cinquantaine de paquets principaux qui produisent un repository personnalisé minimal. Il faut 2h pour compiler l'ensemble des ports (il y en a 171).
Ensuite tu dois juste de temps en temps rajouter/supprimer les logiciels suivant ton besoin. Poudrière s'occupe de gérer correctement les modifications sur les dépendances.
Pour la maintenance, eh bien j'ai un script cron qui toutes les nuits mets à jour l'arbre de ports et compile les ports qui doivent être mis à jour, puis pousse le repository sur le serveur Apache dédié.
Veepee & UNIX-Experience
[^] # Re: Est-ce fonctionnel ?
Posté par MTux . Évalué à 6.
Je ne doute pas de l'utilité et la puissance du truc. Cependant je vais citer deux cas dans lesquels des repositories publics et prêts à l'emploi sont utiles :
Je veux installer FreeBSD sur mon serveur perso, c'est un Atom (donc merdique) bloqué en 32 bits et bridé à 1GB de ram. Il me faut 2h30 pour compiler Postfix. J'ai pas vraiment envie de me taper la compilation de l'intégralité des ports.
Je veux installer FreeBSD au taf, je vais donc devoir convaincre le chef de me donner un deuxième serveur juste pour compiler les ports, et passer plusieurs heures par mois pour maintenir et recompiler les logiciels. Je pense qu'il va m'envoyer sur Debian.
[^] # Re: Est-ce fonctionnel ?
Posté par Loïc Blot (site web personnel) . Évalué à 4.
Pour ton point 1 poudriere permet le cross compiling si je ne dis pas de bêtises, donc cela résoud le souci 32/64. De plus poudriere permet de compiler les ports pour diverses version de freebsd, utile en production sur des serveurs à maintenir 5 ans, là où la plupart des distributions Linux ont déjà abandonné.
Non du tout, la poudriere peut s'occuper de tout toute seule, avec une tâche planifiée cron toutes les nuits (perso dans mon infra c'est une VM avec 2 coeur, 4Go de RAM) qui compile uniquement les pkg dont tu as besoin, et uniquement ceux non compilés ou mis à jour.
Veepee & UNIX-Experience
# librairie
Posté par _jordan_ . Évalué à 4. Dernière modification le 06 septembre 2013 à 18:10.
Tu voulais dire une bibliothèque je suppose.
[^] # Re: librairie
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, parmi divers anglicismes.
# Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Comparaison plus concrète
Posté par Bapt (site web personnel) . Évalué à 5.
Les ports fonctionnent très bien avec pkgng pour info, les fan des ports peuvent continuer a les utiliser avec pkgng.
Pour les différence entre les formats je pense sincèrement que ça n'est pas très important, pour les format de dépôt aussi, il n'y a pas vraiment de diff entre yum/apt/pkgng a ce propos si ce n'est les briques techniques utilisées et je ne pense pas que la valeure ajoutée soit très importante a ce niveau là.
FreeBSD dispose déjà d'un système de paquet binaire depuis 1993, mais il n'était pas top :)
[^] # Re: Comparaison plus concrète
Posté par Anonyme . Évalué à 2. Dernière modification le 06 septembre 2013 à 19:11.
C’est surtout qu’il faut bien faire la différence entre les ports et pkgng. pkgng ne sait pas compiler de ports et les ports ne savent pas gérer les paquets mais les construisent.
Edit: ah merde, j’avais pas vu que c’était toi…
[^] # Re: Comparaison plus concrète
Posté par Bapt (site web personnel) . Évalué à 2.
pkgng ne sais pas compiler des ports, mais les ports savent un minimum gérer les paquets en utilisant pkgng justement :)
[^] # Re: Comparaison plus concrète
Posté par Anonyme . Évalué à 1.
Certes mais ça se limite à l’installation/désinstallation et la création de paquet, me trompe-je ?
[^] # Re: Comparaison plus concrète
Posté par Loïc Blot (site web personnel) . Évalué à 3. Dernière modification le 06 septembre 2013 à 23:17.
J'ajouterais au passage qu'il est possible (testé et approuvé) de passer d'un système utilisant les ports à un système utilisant les packages.
Je suis en train de migrer doucement mes serveurs en ports/serveur vers packages/poudrière personalisée.
le pkg update détecte les ports à mettre à jour et s'il un package du repository est plus récent, il passe en package et fixe les dépendances (généralement remplace le port par le package du repository). De plus le système de repository est capable de détecter un changement d'options de compilation dans une dépendance et ca c'est vraiment top.
Veepee & UNIX-Experience
[^] # Re: Comparaison plus concrète
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 06 septembre 2013 à 16:58.
Et surtout comment ça se situe par rapport à nix qui semble proposer la même chose?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Comparaison plus concrète
Posté par Bapt (site web personnel) . Évalué à 5.
Nix a l'air bien tout ça tout ça, mais il ne faut pas oublier une chose: l'historique.
Il nous fallait prendre en compte l'historique de FreeBSD et permetter une évolution la plus douce possible vers le nouveau système de packages et du coup ça nous as beaucoup limité techniquement nous empêchant de faire quelque chose de comparable a Nix.
Enfin nous avons l'arbre des ports dans lequel sont déjà porté 25 000 packages, ce qui nous apportent du bon et du mauvais, le bon: déjà 25 000 packages possible dès de début, rien de mieux pour confronter son outil a des cas tordus. désavantage nous avons tu faire des choix techniques limitatif pour rentrer dans les clous de l'arbre des ports, enfin les clous je les déplace beaucoup ces derniers temps pour assouplir tout ça :)
[^] # Re: Comparaison plus concrète
Posté par Loïc Blot (site web personnel) . Évalué à 2.
Le plus dur ne sera pas pkgng mais clang :)
Veepee & UNIX-Experience
# .
Posté par eingousef . Évalué à 10. Dernière modification le 06 septembre 2013 à 17:11.
Vous pouvez remercier Lennart !
Voilà. Bonne fin de vendredi à tous.
*splash!*
[^] # Re: .
Posté par Maclag . Évalué à 6.
Plus sérieusement, je serais curieux de savoir ce qui intéresse les entreprises dans FreeBSD.
Ça donnerait un autre point de vue que les discours idéologiques sur la licence.
[^] # Re: .
Posté par Bapt (site web personnel) . Évalué à 10.
Les principales raisons qui m'ont été données par les entreprises qui m'ont contacté :
- Simplicité pour remonter les patchs, avoir un seul upstream unifié pour tout ce qui concerne la base de l'OS est très pratique.
- Simplicité pour produire des images embarquées avec nanobsd.
- POLA (politic of less astonishment) qui signifie que l'on ne casse pas tout du jour au lendemain et que si on casse ont prévoie des procédures de migrations le plus simple et automatique possible.
J'ai reçu plein d'autres raisons mais celles ci sont les raisons majeures.
Parmi les raisons qui m'ont été données qui les font envisager de quitter Linux:
- instabilité des composants (dans les sens ont casse tout et ont recommence.) par exemple udev ses nombreuses cassures de compatibilité, ou encore les hal->devicekit->udev ou encore les systèmes d'init, chez redhat par exemple: scripts -> upstart -> systemd. Beaucoup sont perdues et se posent des questions quand à la pérennité de leurs développements (si je me base sur une brique logicielle, va t elle perdurée, va elle rester compatible, etc)
- trop de "fanatique", les entreprises n'ont pas le temps de mettre en place une infrastructure pour contribuer leur code qu'elles se font déjà harceler. Pour beaucoup ce n'est pas quelque chose de naturel de contribuer le code, elles sont volontaires mais il faut leur laisser le temps de s'organiser.
L'arrivée de pkgnsg et la simplicité de déployer des repos maison est souvent l'excuse qui leur a fait franchir le pas (encore une fois pour celles qui m'ont contacté.)
La license BSD est rarement la raison majeur pour s'intéresser a FreeBSD, Les seuls cas que j'ai rencontré où la license BSD était évoqué concerne des entreprises dont les avocats (pour celles qui en avaient) n'étaient pas capable d'expliquer de manière simple et concrete pour un humain normal ce que la license GPLv3 leur imposait de faire ou non, si il y avait des risques pour eux ou non, parce que la license est trop compliquée. Ces mêmes entreprises avaient précédemment fait la même démarche pour la GPLv2 et l'acceptaient sans soucis.
Dans tous les cas que j'ai rencontré, ces entreprises souhaitent contribuer en retour!
[^] # Re: .
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
D’après les retours que j’ai, j’ajouterais la doc (handbook + man) et la pertinence des réponses que l’on peut trouver sur le web ou les listes de discussions quand on rencontre un problème.
[^] # Re: .
Posté par François Tigeot . Évalué à 10.
J'ajoute quelques points importants pour la route:
Meilleur support matériel serveur
C'est stupide, mais une grande partie des distributions Linux est incapable de fournir une liste du matériel supporté. Je m'étais particulièrement pris la tête avec des gens de Redhat pour une histoire de carte RAID par exemple.
Avec les systèmes *BSD, on a des listes de compatibilité bien précises, comme ici: Contrôleurs disques FreeBSD 9.1
Stabilité système compatible avec des logiciels à jour
Le système d'exploitation et les logiciels tiers sont bien séparés. Il est tout a fait possible de mettre à jour les logiciels applicatifs sans devoir tout chambouler dans le système de base.
Installer et utiliser une version de Dovecot vieille de 15 jours sur un serveur installé il y a 2 ans et n'ayant que des mises à jour de sécurité minimales n'est pas un problème par exemple.
# CUDF
Posté par sifu . Évalué à 3.
J'avais lu à l'époque que cette librairie avait vocation à gérer ces problématique de dépendances.
J'ai pas réussi à trouver beaucoup de news …
http://linuxfr.org/news/cudf-ou-la-r%C3%A9solution-de-d%C3%A9pendances-universelle
[^] # Re: CUDF
Posté par Bapt (site web personnel) . Évalué à 4.
C'est la norme que nous avons suivit pour définir notre nouveau solver car nous voulons respecter les standards au maximum. Donc oui pkgng 1.2 sera capable d'exporter ses informations dans ce format.
[^] # Re: CUDF
Posté par sifu . Évalué à 2.
Question bête: Il me semblait qu'il proposait une librairie avec. Est-ce qu'elle n'était pas utilisable en l'état ? Merci.
[^] # Re: CUDF
Posté par Bapt (site web personnel) . Évalué à 3.
La bibliothèque fournie est minimaliste recodée la notre était tout aussi simple permettant surtout de bien l'intégrer dans pkgng.
[^] # Re: CUDF
Posté par Spyhawk . Évalué à 6. Dernière modification le 07 septembre 2013 à 02:25.
Autre question: Si CUDF est resté plus ou moins un projet qui n'a jamais passé au stade de production, openSUSE développe depuis quelques années un gestionnaire de paquet (zypp) basé sur un solveur sat intégré dans une librairie satsolver (libsolv).
Cette dernière est portable, compatible avec plusieurs formats de paquets et dépôts, et fait intéressant elle sera utilisée dans le nouveau système de paquets DNF de Fedora (à noter que c'est plutôt rare qu'une technologie SUSE devienne l'upstream de Red Hat). En somme, libsolv semble réussir là où CUDF n'a jamais abouti. Le projet pkgng a-t-il considéré cette librairie de résolution SAT de dépendances?
[^] # Re: CUDF
Posté par Bapt (site web personnel) . Évalué à 8.
Ah libsolv :), biensûr que l'on y a pensé très fortement même, libsolv c'est génial ça fait tout ce qui fait mal a la tête pour toi et ça le fait bien, en plus ils sont une license amicale.
Depuis le début du projet j'ai libsolv en tête, et je compte bien l'utiliser. Mais au final libsolv c'est assez intrusif: c'est libsolv qui gère les repo, du coup il faut apprendre a libsolv comment utiliser les repo pkgng, il faut aussi lui apprendre toutes les spécifités de la politique de packaging de l'OS. Bref si on si on utilise libsolv, il faut faire les choses à la libsolv et modifier libsolv lui même pour se faire., disons que à mon gout libsolv n'est pas assez générique, j'aurai aimé le même genre de bibliothèque, mais qui apprennent les spécificités via des callbacks par exemple.
La dernière chose c'est que les structures représentant les packages dans libsolv n'est pas compatible avec les structure représentant les paquets de pkgng (du a des méta donnée de "transition" mais indispensable que l'on a du introduire dans pkgng pour permettre la migration progressive).
Je regarde toujours libsolv du coin de ligne, mais disons que pour le moment ça ne colle pas encore :)
# Précisions sur les différents systèmes de paquetage
Posté par jseb . Évalué à 1.
Bonjour, alors moi je viens de Arch où tout est très simple (pacman pour les binaires, abs pour rester dans le standard et se faire ses paquets, et aur (avec yaourt) pour les PKGBUILD dans le wild).
Après un peu (beaucoup) de lecture, et pour ce que j'en ai compris:
D'un côté on a des binaires, installables avec les pkg_ tools. Ce n'est pas très conseillé, car il n'y a pas grand chose et ça sert surtout à installer un système.
De l'autre, il y a un système à la Gentoo (oui, je sais) avec des makefiles: les ports.
Au fil du temps, les paquets binaires sont donc remplacés par ceux que l'on se construit avec les ports.
Pour les binaires: pkg_add , pkg_info, pkg_delete, pkg_version (pour comparer avec ce qui est dans l'arbre des ports).
La gestion de l'arbre des ports (les makefiles) avec portsnap (portmanager n'est plus à utiliser si j'ai bien compris). Et ensuite, on va dans le répertoire du port et on fait un make config && make . La mise à jour des ports se fait avec portupgrade (make world ?)
Il y a portmaster , mais mes notes ne sont pas très claires. C'est un utilitaire pour suivre les ports, c'est ça ? (mises à jour à faire, etc.)
Les packages à partir d'un port compilé se font avec un make package dans le répertoire du port. (et ensuite donc, on peut les gérer avec les commandes pkg_ données ci-dessus).
freebsd-update : donc ça c'est pour le système de base si j'ai bien compris, c'est à dire que ça ne va pas toucher aux ports installés, mais que ça va pousser le système vers une nouvelle version de la distrib. Donc une série de pkg_delete / pkg_add ?
Et donc, pkgng : si j'ai bien compris, c'est comme faire un makepkg (Arch) ou emerge (Gentoo). Comment se place t-il par rapport aux outils des ports ? Les remplace t-il ? S'occupe t-il de bout en bout de la compilation des ports et création des packages à son format ? Peut-on accéder à une base de paquets précompilés, façon pacman :
[core]
Include = /etc/pacman.d/mirrorlist
?
Voilà en gros ce que j'en ai compris, en bouquinant la doc FreeBSD (c'est pas parce qu'on est bien avec Arch qu'il ne faut pas regarder la concurrence).
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Précisions sur les différents systèmes de paquetage
Posté par Anonyme . Évalué à 4. Dernière modification le 07 septembre 2013 à 13:13.
portmaster et portupgrade permettent de faciliter la mise à jour des ports, et uniquement des ports, pas de make world car ceci est dédié au système de base. Les ports et le système de base sont deux éléments bien distincts qui ne se gère pas de la même façon.
Pas de pkg* ici, le système de base ne se gène pas via des paquets.
Non. pkgng c’est pacman, cd /usr/ports// && make package c’est le makepkg.
Oui, via les paquets compilés par PC-BSD.
[^] # Re: Précisions sur les différents systèmes de paquetage
Posté par Anonyme . Évalué à 2.
Ah et j’ai oublié, portsnap a pour seul but de récupérer, extraire et mettre à jour l’arbre des ports.
[^] # Re: Précisions sur les différents systèmes de paquetage
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Je pense que tu n'as pas saisie l'essentiel.
Freebsd c'est une distribution unix like complète qui s'installe soit par les sources soit de façon binaire.
La seule modularité qu'elle offre est au niveau de sa construction. On peut exclure certains éléments, activer certaines fonctionnalités a la compilation. Mais ensuite freebsd est monolithique.
Les outils sont make, l'installateur et freebsd-update qui grosso modo télécharge et décompresse des tar.
Par ailleurs freebsd offre une facilité pour telechager et compiler des logiciels tiers : les ports.
Les ports sont des makefiles. Ni plus, ni moins. Les logiciels installés par les ports ne sont pas inclus dans freebsd.
Depuis longtemps les ports permettent de fabriquer des paquets binaires afin d'éviter d'avoir a tout recompiler sur chaque machines. Les outils pkg_ servaient a ça. Pkgng les remplace en corrigeant leurs défauts et permet donc de gérer directement de vrai repos binaires a la apt ce qui facilite grandement le déploiement des logiciels tiers et les upgrades.
La distinction entre le système des base et les ports est culturellement très différente de ce qui se pratique dans les distros linux. Apache est dans debian mais pas dans freebsd. Freebsd fournie juste un makefile et des outils pour télécharger, compiler et déployer apache.
# pkgng pour base
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
L'utilisation de pkgng pour le système de base serait sans doute un gros plus. En particulier car ça permettrait de rester en binaire tout en profitant de la modularité du word.
J'imagine bien par exemple des paquets séparés pour sendmail, bind, les trucs audio ou wireless, /rescue …
De plus freebsd-update n'est pas super intuitif (surtout lorsqu'il s'agit de mettre en place un dépôt custom).
Par contre cela nécessiterai que les ports expriment leur dépendances par rapport à base, ce qui n'est pas le cas actuellement.
Par exemple je peux très bien installer un subversion compilé sur un word par défaut sur un système compilé sans support de kerberos. Pkg ne dira rien mais le binaire ne marchera pas car il sera incapable de trouver certaines lib.
Enfin il y a la gestion des fichiers de conf qui est pour l'instant traitée a part de l'installation des binaires. Ce qui me semble contradictoire avec une logique de package.
Bref sans violer la POLA, cela me semble être le bout du monde.
# Récupérer format existant?
Posté par NanoTech . Évalué à 2. Dernière modification le 07 septembre 2013 à 22:44.
Question technique (qui risque de dégénérer au troll):
Vu que pkgng utilise un nouveau format de paquetage binaire (celui de pkg_* étant trop limité), pourquoi ne pas avoir récupéré un format existant comme DEB ou RPM?
Je comprends que l'outil pkgng répond à un besoin, mais le format de paquetage en lui même offre-t-il des fonctions non présentes dans DEB ou RPM?
[^] # Re: Récupérer format existant?
Posté par claudex . Évalué à 6.
Vu le commentaire de Bapt https://linuxfr.org/nodes/99537/comments/1482650 , je dirais qu'il manque des métadonnées dans les formats existants.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Et chez les voisins...
Posté par gaston . Évalué à 10.
Juste pour apporter un complément d'information, avec l'état des lieux comparatif chez OpenBSD (il n'y a pas du tout de compétition avec FreeBSD, chacun son rythme et ses objectifs, et je connais très bien Bapt, donc rangez vos trolls :)
Voili, voilou.. pour plus d'infos se reférer aux différentes présentations de Marc Espie sur http://www.openbsd.org/papers/
[^] # Re: Et chez les voisins...
Posté par Anonyme . Évalué à 5.
Hmm, sur le point de la génération du dépôt, effectivement c’est über simple avec les outils d’OpenBSD, cependant ça n’offre pas la possibilité de faire des requêtes « distantes » et bon, c’est un peu accessoire mais, c’est un peu plus lent pour faire les mises à jour, il me semble (j’ai utilisé un OpenBSD il y a un peu de temps, les souvenirs de ce côté ne sont plus de dernière fraîcheur).
Mais dans l’ensemble… les outils d’OpenBSD sont franchement sayx. D’ailleurs OpenBSD c’est sayx.
[^] # Re: Et chez les voisins...
Posté par gaston . Évalué à 3.
Coté requetes distantes, c'est pkg_info -Q :
Mais c'est beaucoup plus simple d'utiliser sqlports (si on connait SQL) ou sysutils/pkg_mgr pour se balader dans l'arbre des ports.
# Avis sur PBI de PC-BSD
Posté par SPlissken . Évalué à 5.
Bonjour
Je vais peut etre me faire huer mais bon…
J ai utilisé pendant un bon moment un FreeBSD (4 ou 5 ans je sais plus trop) en mode desktop. Puis au bout d un moment j en ai eu marre de geeker et de me casser la tete , lorsque je voulais avoir une version a jour de Firefox, avec les dependances et la lecture de /usr/ports/UPGRADE , meme avec portupgrade et consorts.
Il y a de cela environ 3 mois je suis passé a PC-BSD et ses PBI.
Quel changement !!! Enfin je me fais plus ch… avec tout ça. Bon alors ok , la taille des paquets peut surprendre au debut. Mais vu la taille des DD de nos jour, si on a une connexion correcte c est pas un probleme. Pour madame et monsieur Michue que je suis en train de devenir c est du tout bon.
C'était ma contribution au gestionnaire de package sous BSD.
[^] # Re: Avis sur PBI de PC-BSD
Posté par ariasuni . Évalué à 6.
Le problème c’est que ça peut vite consommer beaucoup de mémoire, et avec 2Go de RAM et KDE + Firefox + LO, je commence déjà à swapper un peu.
Et puis en général c’est plus long à se lancer (c’est toujours moins agréable), ça consomme beaucoup de bande passante (mon débit en téléchargement: 300kio/s), et on écrit beaucoup plus sur le disque, pas super pour les SSD.
Bref, c’est pas super pour du matos d’il y a deux ans, pour les SSD et/ou une connexion qui ne se chiffre pas en Mio/s.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Avis sur PBI de PC-BSD
Posté par Bapt (site web personnel) . Évalué à 7.
Juste pour info, PC-BSD utilise pkgng pour toutes les applicatifs "de base" (X, kde, etc). Ensuite rien n'empeche d'avoir des PBI-like sur pkgng. des PBI ce sont juste de bon gros flat packages, sans dépendance, j'ai déjà fait un PoC pour faire de PBI avec pkgng, du coup tu n'a qu'un seul gestionnaire de package pour gérer les paquets traditionnels et les PBI.
# Puisqu'il y a un expert dans la salle
Posté par reno . Évalué à 4.
As-tu regardé aussi Nix/GNU Guix dans ton étude des gestionnaire de paquets pour Linux?
Çà me parait être un système avec des fonctionnalités avancées..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.