Sortie de Gentoo MacOS

Posté par . Modéré par Benoît Sibaud.
Tags : aucun
0
20
juil.
2004
Gentoo
L'idée d'adapter Portage (le système de ports de la distribution Gentoo Linux) à MacOSX a germé il y a un peu plus d'un an. Peu après a été lancé le projet Metapkg, alliance entre Gentoo, Fink et OpenDarwin, visant à fédérer tous les efforts de portage de logiciels libres vers MacOSX/Darwin.

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.
  • # et les ports ?

    Posté par . Évalué à 5.

    à noter qu'il ny'a pas que fink et portage.

    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 . Évalué à -1.

      D'ailleurs, ca m'a légérement agacé de voir de-ci de-la que portage et emerge c'etait trop révolutionnaire. C'est limite si je suis passé pour un ane en parlant de apt-get aux gentoïstes: "han, apt-get c'est has been, emerge c'est trop bien....". Ouais sauf que moi, ca fait un moment que j'utilise les ports sous FreeBSD, donc rendons ce que est a César ce qu'y lui a appartient.

      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 . Évalué à -3.

        ben vi enfin, gentoo strop puissant ! (surtout l'hiver pour se chauffer en fait ;) )
      • [^] # Re: et les ports ?

        Posté par . Évalué à 6.

        En essayant de faire fi des nombreux trolls du à la sensibilité les utilisateurs à leur gestionnaire de paquets, on peut quand même reconnaître une originalité certaine à Portage vis à vis des ports BSD.

        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 (page perso) . Évalué à 1.

          Tout comme tu poses tes variables qui affectent les ports et/ou le makeworld du système dans le make.conf de FreeBSD, mk.conf de NetBSD, je ne sais pas ce qu'il en est d'Open mais ca doit surement exister.
          Pas aussi élégant que le /etc/portage/packages.use, mais bien assez efficace.
          • [^] # Re: et les ports ?

            Posté par . Évalué à 4.

            Heu le make.conf ne permet pas du tout de regler la meme chose que le packages.use hein.

            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 . Évalué à 4.

          tu insinuerais que les packageurs de Debian (et autres) mettent des dépendances sur tout et n'importe quoi quand ils compilent leurs bidules ? dont certaines vraiment en dépit du bon sens ? un xemacs qui aurait eu un jour des dépendances à la con vers LDAP et PostgreSQL ?

          ça se saurait !
          • [^] # Re: et les ports ?

            Posté par . Évalué à 2.

            mdr, j'ai deja vu ca :p

            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 (page perso) . Évalué à -1.

        Tellement révolutionnaire qu'il n'y a pas de gestion des dépendances inverses, c'est à toi de savoir si en retirant X ou Y ça cassera tout ton système. 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.
        • [^] # Re: et les ports ?

          Posté par . Évalué à 2.

          Et pourtant, le package gentoolkit fournit toute une série d'utilitaires bien pratiques (dont malheureusement il n'est pas fait beaucoup de pub au niveau du projet et qui n'est pas énormément documenté...) et notamment etcat qui permet justement de faire les vérifications de dépendances inverses.
          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 . Évalué à 4.

          c'est à toi de savoir si en retirant X ou Y ça cassera tout ton système

          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 . Évalué à 1.

            Si on en est au critique de portage, moi la seule chose qui me gène, c'est qu'il ne gère pas les dependances sur les USE :

            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 . Évalué à 3.

              la seule chose qui me gène, c'est qu'il ne gère pas les dependances sur les USE

              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 . Évalué à 2.

        "Gentoo veut-il monopoliser toutes les plateformes ?"
        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 (page perso) . Évalué à -1.

          ah bon, n'ai-je jamais entendu d'un port de portage pour ces UNIX là ?
          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 . Évalué à 0.

      on y trouve même les ports NetBSD pour Os X : http://pkgsrc.org/(...)
  • # Mon petit avis sur portage

    Posté par . Évalué à 2.

    Portage, ça fonctionnait, mais à l'époque ou j'utilisais, c'était affreusement lent pour questionner ( emerge -S et emerge -s, demande de calcul des dépendances)

    vivement qu'ils utilisent une vraie db, car c'est vraiement pénible par moments.
    • [^] # Re: Mon petit avis sur portage

      Posté par . Évalué à 2.

      C'est possible. Il suffit d'emerge esearch.
      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 . Évalué à 2.

        Moi aussi j'utilise esearch, mais c'est vrai qu'une vraie db pour chercher plus vite ca aiderait :` ( pi j'imagine que ca accélèrerait d'autres choses aussi ... )
        • [^] # Re: Mon petit avis sur portage

          Posté par . Évalué à 1.

          Mais tu perds du coup en souplesse, qui est a mon avis le pourquoi de l'utilisation d'une arborescence sur le fs
      • [^] # Re: Mon petit avis sur portage

        Posté par (page perso) . Évalué à 1.

        Tiens un revenant ? Ecris un mail a l'occasion. Desole de passer ca en forum mais j'ai pas trouve d'email pour te contacter.

        Steph
  • # "...sous Gentoo MacOS, ils sont intégrés à la hiérarchie standard"

    Posté par . Évalué à 2.

    Euh, je me demande vraiment si c'est une bonne idée: les mises-à-jours apple sont connue pour écraser sans ménagement tout sur leur passage. J'imagine bien les problèmes que ca va causer...

    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 . Évalué à 2.

      Oui c'est vrai il y a eu quelques problemes par le passé. Mais AppleX11 ne me cause plus de soucis même au gré des mises à jour.
      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 . Évalué à 2.

      Bonjour,

      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 . Évalué à 3.

    Un truc que j'ai oublié de rajouter à la niouze c'est qu'il y a un chan IRC #gentoo-osx sur freenode. C'est là que j'ai eu les qlqs précisions nécéssaire lors de la modération. Y'a du monde dessus, il sont gentils, tout ça, donc hésitez pas.

Suivre le flux des commentaires

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