Aujourd'hui, après un an de travail, l'équipe de 20 développeurs réunis par Pieter van den Abeele et Daniel Ostrow est fière d'annoncer Gentoo MacOS, une intégration de Portage dans MacOSX opérationnelle et transparente. En l'état actuel, le système permet déjà l'installation de nombreux logiciels sur MacOSX, même si on est encore loin d'avoir à disposition la totalité des ports existants sous Gentoo Linux.
Comparé à Fink (qui se base sur dpkg), Gentoo MacOS se distingue par les avantages et inconvénients de Portage : par exemple, l'utilisateur bénéficiera de la souplesse que confèrent les USE flags, mais en contrepartie il n'aura pas la sécurité d'une vraie gestion des dépendances inverses. Une autre différence fondamentale est l'emplacement d'installation des paquets : sous Fink, ceux-ci sont installés dans une branche dédiée du système de fichiers, alors que sous Gentoo MacOS, ils sont intégrés à la hiérarchie standard. Gageons que chaque système aura son lot de fidèles, l'important étant que chacun trouve son compte dans un camps au moins.
Mais le projet ne devrait pas s'arrêter à l'installation de logiciels supplémentaires sur un système déjà fonctionnel, explique Pieter van den Abeele : «Dans quelques mois, nous aurons un système de ports capable de construire Darwin de zéro, fournissant des procédures standardisées de construction et d'installation pour les éléments du Dashboard, des améliorations et des outils comme le Desktop Manager, et bien d'autres applications OS X très populaires.» Est aussi prévue la possibilité de déployer des mises à jour en réseau via le système iSync d'Apple.
Télécharger l'installateur de Gentoo MacOS fournit aux utilisateurs une version modifiée de Portage, un arbre de ports (ou ebuilds), et l'ensemble des modules Python nécessaires. Cet installateur définit alors les variables d'environnement requises et utilise un shell d'initialisation au premier lancement d'emerge (la commande d'installation des paquets), qui détecte la version du système (Panther ou Tiger), choisit le profil adéquat, et injecte dans la base des paquets installés les applications et bibliothèques déjà présentes sur le système.
Voir une capture d'écran de cette dernière phase. D'autres captures sont accessibles depuis l'annonce GWN.
NdM : merci à l'auteur de cette dépêche de bien vouloir nous excuser de l'avoir presque intégralement réécrite.
Aller plus loin
- L'annonce (Gentoo Weekly Newsletter) (8 clics)
- Le système Portage (18 clics)
- Téléchargement (.dmg) (32 clics)
- Gentoo_MacOS Wiki (38 clics)
- Le site de Metapkg (9 clics)
- Le site de Fink (5 clics)
# et les ports ?
Posté par Psychofox (Mastodon) . Évalué à 5.
Il y'a aussi le système des ports de opendarwin, si cher aux BSD.
http://darwinports.opendarwin.org/ports/(...)
[^] # Re: et les ports ?
Posté par Raphael R . Évalué à -1.
Surtout qu'il y a deja de l'existant avec OpenDarwin, pour ajouter ca ? Gentoo veut-il monopoliser toutes les plateformes ? :]
[^] # Re: et les ports ?
Posté par Flink . Évalué à -3.
[^] # Re: et les ports ?
Posté par Arachne . Évalué à 6.
L'utilisation des USE permet une grande souplesse dans le choix des fonctionnalités des applis que l'on installe, et les derniers changements de Portage vont dans ce sens : possibilité de spécifier ses variables USE par package (comme le fait SourceMage d'une certaine manière) ou d'utiliser des versions stables d'un ebuild et instables d'un autre. Certains dingues veulent même spécifier des paramètres de compilation (CFLAGS) pour chaque logiciel! cf. http://linuxfr.org/2004/03/31/15867.html(...)
Je suis loin d'être un inconditionnel, il n'empêche que le système est intéressant. Après, savoir si c'est utile à ses utilisateurs, c'est autre chose... :)
[^] # Re: et les ports ?
Posté par twisla (site web personnel) . Évalué à 1.
Pas aussi élégant que le /etc/portage/packages.use, mais bien assez efficace.
[^] # Re: et les ports ?
Posté par ckyl . Évalué à 4.
Ce qui se reproche le plus c'est le pkgtools.conf mais c'est pas tres user friendly a grande echelle :-)
http://www.freebsd.org/cgi/cvsweb.cgi/src/share/examples/etc/make.c(...)
Pour rappel le make.conf permet de choisir les options passées a gcc pour la compilation et différent parametres tel que les logiciels a construire en même temps que le monde ou encore les modules noyaux a compiler (et quelques autres choses). Mais il ne permet surement pas la gestion de dépendences; ce dont on parle ici.
[^] # Re: et les ports ?
Posté par Gniarf . Évalué à 4.
ça se saurait !
[^] # Re: et les ports ?
Posté par Stephen Amar . Évalué à 2.
ou sinon un gestion des retrodépendance trop forte, genre apt-get vire gnome
car tu desinstalle une application utilisant gtk
[^] # Re: et les ports ?
Posté par Éric (site web personnel) . Évalué à -1.
[^] # Re: et les ports ?
Posté par sk . Évalué à 2.
Extrait de l'aide:
depends (-d short option)
Finds all packages that are directly dependent to a regex search stri-
ng.
Autre outil sympathique, revdep-rebuild, pour le cas où tu aies supprimé un paquetage qu'il fallait pas. Le script va parcourir l'ensemble du système à la recherche d'un paquet cassé et va le réemerger automatiquement avec les bonnes dépendances.
[^] # Re: et les ports ?
Posté par tgl . Évalué à 4.
Le cas que tu cites, il est très facile à éviter. D'une part il y'a des outils pour ça, qui savent vérifier les dépendances inverses (qpkg, equery, etc.) et qui permettent de contrôler si un package est ou non nécéssaire à la bonne marche du système, donc l'utilisateur qui sait se servir d'une gentoo ne tombe pas dans ce genre de panneaux. De plus, le plus gros des désinstallations se fait par nettoyage, pas par suppression explicite (encore heureux tu me diras) : tu demandes de supprimer une application de ton world, puis tu fait un "depclean" pour supprimer aussi ses éventuelles anciennes dépendances qui ne seraient plus nécéssaires à aucun autre package.
Enfin bref, tu peux le croire ou pas, mais vraiment les désinstallations explicites qui cassent le systèmes ou d'autres paquets c'est juste des erreurs de débutants. (Après, on peut aussi considérer qu'il devrait y avoir des garde-fous systématiques plutôt que des bonnes pratiques à connaitre, ça se défend, c'est une autre approche).
Mais là où l'absence de gestion des dépendances inverses par "emerge" lui même pose problème, c'est dans des cas de ce genre là :
- tu as d'installé pkgA qui dépend de libfoo en version 1.0*
- tu veux installer pkgB qui dépend de libfoo 0.9*
- libfoo n'est pas packagé de façon à ce que la 1.0 et la 0.9 puissent cohabiter
=> "emerge pkgB" va passer par une installation d'une version 0.9.x de libfoo, et donc la désinstallation de la 1.0.y. Il casse au passage pkgA.
En pratique, ce genre de cas sont prévenus à la main par les packageurs (par exemple ils vont marquer pkgA et pkgB comme mutuellement exclusifs puisqu'ils ne peuvent pas cohabiter), mais encore faut-il détecter le danger (pas évident pour le mainteneur responsable de pkgA et qui n'a pas forcement pkgB sur son système), et du coup ça n'est souvent fait qu'une fois qu'un utilisateur des versions instables est tombé dedans. Là, une gestion intégrée des dépendances inverses serait biensûr la seule solution vraiment universelle.
C'est bien, ça marche, il y a des possibilités intéressantes, mais il n'y a pas de quoi refouler apt/urpmi et yum, vraiment pas.
Perso, en plus de deux ans d'utilisation de la branche testing de gentoo, j'ai vu eu une fois un problème attribuable à l'absence de gestion des dépendances inverses (un dowgrade de xvid qui cassait mon xawdecode). Je considère que c'est vraiment très négligeable comparé aux avantages spécifiques à Portage, mais ça n'est biensûr que mon avis.
[^] # Re: et les ports ?
Posté par Alex . Évalué à 1.
un package depend de python-tk
on a compilé python sans le flag tk -> ca plante et on sait pas pourquoi...
Sinon j'adore portage, c'est simple et souple, manque peut etre de performances, un emerge search -S peut prendre une dizine de minutes, il y a bien des outils pour compenser (esearch), mais qui demande la reconstruction d'une base de temps en temps.
[^] # Re: et les ports ?
Posté par tgl . Évalué à 3.
Oui, effectivement, ça c'est un peu génant. Et c'est une très vieille feature request aussi :
http://bugs.gentoo.org/show_bug.cgi?id=2272(...)
C'est malheureusement vraiment pas évident d'ajouter ça proprement vu la façon dont emerge calcule ses dépendances (le pb est assez proche de celui des deps inverse en fait : en gros l'algo d'emerge est glouton alors qu'il faudrait backtracker à certains endroit). Là encore, vu qu'il y a des workaround possibles (cf. mon paragraphe suivant), je crains que ces gros changement n'arrivent pas de ci tôt dans portage... Et portage-ng est encore loin.
un package depend de python-tk
on a compilé python sans le flag tk -> ca plante et on sait pas pourquoi...
Il faut faire un bug report sur le paquet en question. Ce qu'on fait en général dans ces cas là c'est qu'on teste dans l'ebuild que python-tk est bien installé et on echoue l'installation du paquet si ça n'est pas le cas, avec un petit message qui dit que il faut réemerger python avec le flag tk. Je parle bien là de tests complètement adhoc, dans ce cas par exemple ça consistera à tester en python l'import du module en question. C'est pas terrible, mais ça évite d'installer des paquets cassés. Bref, c'est bel et bien un bug de l'ebuild si ça n'est pas fait.
[^] # Re: et les ports ?
Posté par pikapika . Évalué à 2.
sans vouloir troller, je pense que Debian est plutôt numéro un sur ce créneau (cf les diverses debian/net bsd et free bsd)
[^] # Re: et les ports ?
Posté par Baptiste SIMON (site web personnel) . Évalué à -1.
mais bon, l'idée de distro-source blindée, ca permet en effet d'imaginer bcp de choses, faisant voir "Gentoo In^MFoundation" un peu partout.
/me restera un trolleur invétéré sur le sujet, rien que parce qu'ils le valent bien ;c) inventor.gentoo.org forever !!!!
[^] # Re: et les ports ?
Posté par pikapika . Évalué à 0.
# Mon petit avis sur portage
Posté par farib . Évalué à 2.
vivement qu'ils utilisent une vraie db, car c'est vraiement pénible par moments.
[^] # Re: Mon petit avis sur portage
Posté par nemerid . Évalué à 2.
Ensuite, tu fais un eupdatedb et tu peux questionner l'arbre comme bon te semble.
Tu as même la commande esync qui te fais le emerge rsync et le eupdatedb en même temps :)
[^] # Re: Mon petit avis sur portage
Posté par MsK` . Évalué à 2.
[^] # Re: Mon petit avis sur portage
Posté par Alex . Évalué à 1.
[^] # Re: Mon petit avis sur portage
Posté par FRLinux (site web personnel) . Évalué à 1.
Steph
# "...sous Gentoo MacOS, ils sont intégrés à la hiérarchie standard"
Posté par swix . Évalué à 2.
swix, qui va probablement rester encore un certain temps avec fink :-)
[^] # Re: "...sous Gentoo MacOS, ils sont intégrés à la hiérarchie standard"
Posté par xylpho . Évalué à 2.
Par contre, GentooMacos c'est un vrai bonheur pour moi. Avant j'avais une gentoo sur mon pc et là je me retrouve en terrain connu. Fink fonctionne très bien mais je suis moins à l'aise avec.
Un truc oublié dans le howto de Gentoo pour l'install sur OSX. Le shell doit être OBLIGATOIREMENT Bash. Ca ne fonctionne pas avec tous les autres.
[^] # Re: "...sous Gentoo MacOS, ils sont intégrés à la hiérarchie standard"
Posté par revponpuneq . Évalué à 2.
Personnellement, je ne pense pas que ce portage, même s'il est très respectable d'un point de vue technique, aide vraiment ceux qui essaient d'utiliser GNU / Linux (Debian, YDL...) ou autre chose de vraiment libre sur une machine Apple.
Ainsi, cela ne va pas aider ni inciter Apple à donner des infos sur le fonctionnement du matériel, c'est même le contraire qui risque de se passer. En plus, livrer toutes les applis Linux sur un plateau sans contre-partie, ils sont très contents chez Apple...
J'ai hâte de voir comment Apple va remercier la communauté, mais je me fais de moins en moins d'illusions... Bref, pas glop
--
eric bachard [ powerbook alu15" + Debian sid ]
# un peu tard mais...
Posté par tgl . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.