Pour ceux qui connaissent pkgsrc (pour les autres, plus d'infos plus bas)
Pour ceux qui s'intéressent à d'autres systèmes que Linux, et notamment à NetBSD, vous serez probablement content de savoir que pkgsrc2014Q1 est sorti. (voir l'annonce ).
Pour ceux qui ne connaissent pas PKGSRC :
Qu'est-ce que pkgsrc
pkgsrc est un système de gestion de paquets cross-platforms.
Il permet aux utilisateur de compiler leurs logiciels à partir des sources et d'installer les paquets binaires de façon identiques sur des plates-formes différentes. Ce système permet de gérer les dépendances lors de la "construction" des paquets, de façon automatique (pas comme sous une slackware de base ou pour chaque dépendance, il faut télécharger, compiler et installer manuellement les paquets).
pkgsrc est le système de paquets utilisé sous NetBSD, mais il est aussi disponible pour de nombreux systèmes différents, dont GNU/Linux (je l'ai personnellement utilisé à une époque sous Slackware). Bien que prévu à l'origine pour une installation à partir des sources, il est capable également de gérer les installations de paquets binaires. A l'origine elles se faisaient via pkg_add/pkg_delete, mais depuis quelques temps, un outil ressemblant plus ou moins à apt sous Debian (ou yum sous Redhat), et nommé pkg_in permet de gérer plus facilement et plus efficacement l'installation de paquets binaires.
A ce jour, pkgsrc est disponible pour :
* AIX
* BSDOS
* Cygwin
* Darwin/Mac OS X
* DragonFly
* FreeBSD
* FreeMiNT
* GNU/kFreeBSD
* HPUX
* Haiku
* IRIX
* Interix/SFU/SUA
* Linux
* Minix3
* MirBSD
* NetBSD
* OSF1
* OpenBSD
* QNX
* SCO OpenServer
* Solaris/illumos
* UnixWare
Utilité de pkgsrc sous GNU/Linux ?
Un système GNU/Linux est un ensemble (normalement) cohérent, dans lequel on ne sépare que rarement la partie OS de base et userland (les applicatifs). Ceci peut être très pratique, mais dans certains cas, ça peut poser problème : une mise à jour d'un élément applicatif peut, par le jeu des dépendances déclencher une mise à jour du système qui peut perturber d'autres applicatifs qui tournent sur le système ( se produit souvent lorsque des softs proprios et des softs libres doivent cohabiter sur la même machine, et que les softs propriétaires n'évoluent pas au même rythme que la distribution).
En séparant la partie système de la partie applicative, on s'affranchit dans une certaine mesure de ces problématiques. Une mise à jour d'un soft libre userland via pkgsrc pourra se faire en recompilant sur une plate-forme identique à celle de production au niveau des couches "de base" ( conforme aux prérequis du ou des softs propriétaires tournant sur le système ). ainsi, OS, userland libre et userland proprio peuvent cohabiter ensemble, et cette façon de faire peut permettre de ne pas trainer de vieilles versions de paquets libres juste pour satisfaire les dépendances propres à un soft proprio (que l'on paye souvent cher).
Le second intérêt se trouve lorsqu'on administre un parc hétérogène : on se trouve ainsi avec les mêmes versons de softs installés sur tous les OS, de la même manière, sans devoir passer par les outils propres à chaque plate-forme (qui sont parfois rudimentaires sur certains systèmes).
Parmi les inconvénients de cette solution, on peut citer le fait que tous les paquets dispo nativement sur la distribution ne seront pas disponibles, ou seront disponibles mais avec quelques versions de retard (à relativiser peut-être si on compare avec la version des paquets fournis sur Debian stable). Les mises à jour ont normalement lieu 4 fois par an, ce qui permet quand meme de ne pas avoir de paquets trop vieux.
Quelques chiffres :
14255 paquets pour NetBSD-current/x86_64
13841 paquets binaires construits via clang pour NetBSD-current/x86_64
11445 paquets binaires construits via gcc pour FreeBSD 9/x86_64
11233 paquets binaires construits via clang pour FreeBSD 10/x86_64
222 paquets ont été ajoutés sur cette version, 33 paquets supprimés, 1 paquet "downgradé"
1681 paquets mis à jour
En conclusion
Rien à dire de plus, sinon : A vos mises à jour !!!
# A l'attention d'un modérateur
Posté par totof2000 . Évalué à 3.
Pouvez-vous SVP suprimer le tag NetBSD sur le titre ? J'ai oublié de l'enlever. En effet, initialement j'étais parti sur un journal plutôt orienté NetBSD, mais au cours de la rédaction, je suis parti dans une autre direction.
Merci d'avance.
[^] # Re: A l'attention d'un modérateur
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé.
[^] # Re: A l'attention d'un modérateur
Posté par totof2000 . Évalué à 2.
Merci :)
# Concrètement
Posté par Le Gab . Évalué à 3.
Qu'est-ce que ça veut dire? Ça fait des années qu'on vante le côté multi-platforme de pkgscr que c'est trop bien et perso j'aime bien l'idée, des milliers de paquets etc… Qu'est-ce qui fait que cette solution n'ait pas encore éradiqué les dpkg, rpm et autres tar.xz alors qu'on sait très bien la galère que c'est, notamment dans un parc hétérogène?
Par contre, qu'en est-il du contrôle qualité? Comment un paquet pkgsrc est-il promu "stable", comment se fait le suivi de sécurité? Comment NetBSD assure t-il le suivi de tous ça? Ils n'ont pourtant pas la force de frappe d'une Debian ou d'une Redhat.
En tous cas, merci pour l'article et d'avoir rappelé cette solution.
[^] # Re: Concrètement
Posté par claudex . Évalué à 3.
Déjà, ce n'est pas des paquets binaires, c'est un inconvénient pour beaucoup de monde. Ensuite, comme pour beaucoup de chose, il y a un problème d'œuf et de poule, peu de monde l'utilise parce que peu de monde l'utilise.
« 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
[^] # Re: Concrètement
Posté par Le Gab . Évalué à 1.
Et donc, son efficacité reste encore à prouver et il se pourrait que ça ne soit pas si rose que ça? Du moins, dans le monde Linux.
[^] # Re: Concrètement
Posté par totof2000 . Évalué à 2.
Pourquoi ?
C'est une alternative qui peut se révéler utile dans certains cas, mais qui n'a pas pour but de remplacer les systèmes de packages natifs des distributions. Je vois deux raisons à ça : le nombre de paquets supportés moins important en général que celui de la distrib, et le léger retard lors de la mise à disposition d'un paquet.
[^] # Re: Concrètement
Posté par reynum (site web personnel) . Évalué à 3.
Peut être parce que "Debian Package" (dpkg) ou alors "Redhat Package Manager" (rpm) ça flatte plus l'ego des dev et autres personnes qui s'occupent de leur distrib chérie que pkgscr ?
Ou alors peut être que ce gestionnaire manque encore de fonctionnalités que proposent les autres ?
Perso je rêve d'un type de paquet unique qui puisse fonctionner sur toutes les distribs et même pourquoi pas sur toutes les architectures (tant qu'à rêver autant le faire bien :-D), qui s'installe aussi facilement et qui soit aussi bien géré (dépendances, désinstallation,…) qu'un deb avec apt, pour moi ce serait une avancée majeure du logiciel sur Linux. Car les libristes et éditeurs pourraient concentrer leurs efforts sur un seul paquet au lieu de 2 (deb,rpm) ou plus si on ajoute les packages arch ou gentoo.
kentoc'h mervel eget bezan saotred
[^] # Re: Concrètement
Posté par claudex . Évalué à 5.
Ça ne risque pas d'arriver, parce que ça implique au final des changements énormes dans les distributions : avoir les mêmes versions de logiciels présents dans les dépôts, avec les mêmes options de compilation, avoir la même libc, avoir les mêmes noms pour les paquets et le même découpage. Au final, n'avoir qu'une seule distribution. Une partie de ces problèmes sont réglés par pkgsrc mais c'est parce qu'il compile les paquets sur le système où il s'installe, ce qui est loin d'être pratique pour l'utilisateur final (les temps d'installation et de mise à jour deviennent long).
Au final, ce n'est pas vraiment la distinction RPM/DEB qui rend compliqué le travail d'empacketage (au final, les deux paquets sont juste un makefile avec une liste des dépendances). Mais ce sont les spécificités de la distribution (trouver le nom des dépendances, patcher le logiciel pour qu'il utilise les bons chemins, écrire une manpage pour le binaire, un .desktop pour l'application graphique…).
« 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
[^] # Re: Concrètement
Posté par rakoo (site web personnel) . Évalué à 2.
Tiens, sur le sujet, j'ai vu fpm l'autre jour, peut-être que ça t'intéressera.
[^] # Re: Concrètement
Posté par totof2000 . Évalué à 2.
Comme dit plus haut, le fait qu'à la base il s'agit d'un "framework" de compilation de paquets à partir des sources. L'ajout de paquets binaires avant pkgin pouvait être assez compliqué. pkgin améliore beaucoup les choses mais il y a encore des cas ou il se vautre un peu.
pkgin est une réponse à ces manques.
[^] # Re: Concrètement
Posté par barmic . Évalué à 2.
Il y a déjà pas mal de coopération entre le développeurs des différentes solutions, notamment pour la résolution des dépendances.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# ebuild
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2.
En fait un pkgsrc, c'est un peu une sorte « d'ebuild » gentoo n'est-ce pas ? Est-ce le type de paquet utilisé par défaut sous NetBSD ? Ou d'autres systèmes/distributions ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: ebuild
Posté par zul (site web personnel) . Évalué à 3.
Historiquement, c'est plutôt le contraire mais c'est ça l'idée. Portage, c'est une réécriture de ports / pkgsrc en utilisant des outils "modernes" (en l'occurence Python).
C'est utilisé par défault par NetBSD. Il y'a d'autres utilisateurs (genre SmartOS). Je l'ai longtemps utilisé sur mes slackware. Jusqu'à peu, c'était aussi le système par défault de DragonFly. Et j'en oublie très certainement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.