et les ports ?

• [+] [^]Re: et les ports ?

  Posté par Raphael R () le 20/07/2004 à 14:58. (lien). É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 Flink () le 20/07/2004 à 15:06. (lien). Évalué à -3.

    ben vi enfin, gentoo strop puissant ! (surtout l'hiver pour se chauffer en fait ;) )

  • [^]Re: et les ports ?

    Posté par Arachne (page perso, ) le 20/07/2004 à 15:11. (lien). É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 twisla (page perso, ) le 20/07/2004 à 15:23. (lien). É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.

      --
      twisla

      • [^]Re: et les ports ?

        Posté par cykl (Jabber id, ) le 20/07/2004 à 15:40. (lien). É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 Gniarf () le 20/07/2004 à 15:39. (lien). É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 !

      --
      Windows has no users. It has hostages.

      • [^]Re: et les ports ?

        Posté par Acetik () le 20/07/2004 à 16:35. (lien). É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 Éric (Jabber id, page perso, ) le 20/07/2004 à 17:47. (lien). É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 sk () le 20/07/2004 à 18:22. (lien). É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 tgl () le 20/07/2004 à 18:46. (lien). É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 Alex () le 21/07/2004 à 08:32. (lien). É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 tgl () le 21/07/2004 à 12:57. (lien). É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 pikapika () le 20/07/2004 à 17:54. (lien). É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 Baptiste SIMON (Jabber id, page perso, ) le 21/07/2004 à 08:25. (lien). É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 !!!!

      --
      BeTa

• [^]Re: et les ports ?

  Posté par pikapika () le 20/07/2004 à 17:49. (lien). Évalué à 0.

  on y trouve même les ports NetBSD pour Os X : http://pkgsrc.org/(...)

Mon petit avis sur portage

• [^]Re: Mon petit avis sur portage

  Posté par nemerid (page perso, ) le 20/07/2004 à 18:37. (lien). É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 MsK` () le 20/07/2004 à 22:53. (lien). É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 ... )

    --
    \_o<~~~~

    • [^]Re: Mon petit avis sur portage

      Posté par Alex () le 21/07/2004 à 08:36. (lien). É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 FRLinux (page perso, ) le 21/07/2004 à 13:58. (lien). É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"

• [^]Re: "...sous Gentoo MacOS, ils sont intégrés à la hiérarchie standard"

  Posté par xylpho (page perso, ) le 21/07/2004 à 16:43. (lien). É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 revponpuneq () le 21/07/2004 à 22:00. (lien). É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...