fiable ?

• [^]Re: fiable ?

  Posté par Victor STINNER (page perso, ) le 03/11/2006 à 14:10. (lien). Évalué à 5.

  Avec "./configure --prefix=/Program/Nom/Version" et deux/trois autres bidouilles ça doit marcher non ?
  
  Selon la doc, GoboLinux semble conserver une arborescence classique (bin, etc, lib, etc.) pour chaque programme. Hum, ça doit faire beaucoup de dossiers tout ça :-)
  
  Haypo

• [^]Re: fiable ?

  Posté par d-jo (page perso, ) le 03/11/2006 à 14:15. (lien). Évalué à 3.

  tout ce qui vient d'UNIX marche. Y compris ./configure && make && make install.
  
  Ceci dit, c'est comme avec toute les distribs, rien ne dit que ces commandes vont respecter les conventions pour placer les fichiers (voire les /opt et autres /usr/local).
  
  Il y a un utilitaire tres simple qui s'appelle Compile et qui permet de créer des paquets sources tres facilement.
  
  L'idée étant juste qu'il semble plus logique que /proc s'appelle : /System/Kernel/Status et /dev /System/Kernel/Devices
  
  /dev/null reste toujours au même endroit.

• [^]Re: fiable ?

  Posté par Aldoo (Jabber id, ) le 03/11/2006 à 14:18. (lien). Évalué à 2.

  Apparemment, en précisant le préfixe pertinent, ça devrai marcher :
  
  ./configure --prefix=/Programms/foo/3.0/
  make
  make install
  
  Et puis pour mieux intégrer, quelques liens s'imposent :
  rm /Programs/foo/current
  ln -s /Programs/foo/3.0/ ln -s /Programms/foo/current
  ln -s /Programms/foo/current/bin/foo /Executables/foo
  etc...
  
  La question c'est s'il y a moyen d'automatiser ces liaisons, qui peuvent être assez fastidieuses si le programme contient plusieurs dizaines de bibliothèques partagées et exécutables.

  • [^]Re: fiable ?

    Posté par d-jo (page perso, ) le 03/11/2006 à 14:23. (lien). Évalué à 2.

    http://gobolinux.org/index.php?page=compile
    
    

    Some of Compile's distinctive features:
    
    * uses the projects' own download sites: the distribution's repository (or one of its mirrors) is only used for downloading recipes. Recipes may be downloaded on-the-fly or in batch.
    * minimalistic and declarative-oriented compilation scripts: typical "configure; make; make install" software can be scripted in two lines, greatly easing maintanance.
    * supports GoboLinux-style dependencies: software compiled "by hand" by the user is taken into account by the detection mechanism.
    * path-agnostic by design: also works in a Rootless-GoboLinux installation, ie, inside a $HOME directory of any other distribution.
    

  • [^]Re: fiable ?

    Posté par Marc Poiroud (Jabber id, page perso, ) le 03/11/2006 à 14:26. (lien). Évalué à 2.

    La question c'est s'il y a moyen d'automatiser ces liaisons,

    
    
    Avec un script bash ... à l'exemple des Slackbuilds de Slackware, bref à l'ancienne comme chez mamie ;)

    --
    La chanson est une industrie parce qu’une poignée d’imbéciles a réussi à être moins con que le reste.
    (Coluche)

  • [^]Re: fiable ?

    Posté par HSimpson () le 03/11/2006 à 14:41. (lien). Évalué à 1.

    La question c'est s'il y a moyen d'automatiser ces liaisons, qui peuvent être assez fastidieuses si le programme contient plusieurs dizaines de bibliothèques partagées et exécutables.
    
    On pourrait pas faire ça à coup d'inotify?

  • [^]Re: fiable ?

    Posté par hisham () le 05/11/2006 à 04:57. (lien). Évalué à 6.

    La question c'est s'il y a moyen d'automatiser ces liaisons, qui peuvent être assez fastidieuses si le programme contient plusieurs dizaines de bibliothèques partagées et exécutables.

    
    
    Salut! Je suis un 'dev' de GoboLinux (pardon mon très mal Français, je ne suis pas qu'un étudiant. :) )
    
    Ce procédure que vous avez décrit est automatisée pour le script SymlinkProgram: il fait toutes des liasons nécéssaires. Aussi, le script Compile utilise SymlinkProgram automatiquement en la fin de la compilation.

Très intéressant

• [^]Re: Très intéressant

  Posté par Aldoo (Jabber id, ) le 03/11/2006 à 14:20. (lien). Évalué à 3.

  Apparemment, il suffit de supprimer pour désinstaller.
  
  Ensuite il est facile d'avoir un script qui fasse le ménage dans les liens cassés (d'ailleurs, j'imagine qu'il doit être fourni... ).

Deux choses

j'ai cru qu'on l'avait

Interessant

• [^]Re: Interessant

  Posté par GnunuX (Jabber id, page perso, ) le 04/11/2006 à 09:09. (lien). Évalué à 1.

  Même si c'est assez pompé sur MacOS !

  
  
  Mouef, c'est pas exactement ca. Si tu parle de .dmg, se sont des sortes d'isos que tu monte avec tout à l'intérieur. Tu peux déplacer ton dmg et tout sans soucis. C'est pas mal différent de lien symbolique et de répertoire.
  
  

  même si certaines limitations sembles exister pour l'instant (/dev/null)

  
  
  C'est quoi le problème avec /dev/null ? Il n'y a pas de problème avec /dev/null.
  
  

  tous les logiciels ne doivent pas êtres très compatible, ce qui laisse présager un gros travail pour les mainteneurs des paquets

  
  
  Euh, hu ? Compatible avec ... quoi ? C'est quoi ce problème que tu essaye de pointer ?

  • [^]Re: Interessant

    Posté par Tonton Benoit (Jabber id, ) le 04/11/2006 à 14:36. (lien). Évalué à 1.

    Mouef, c'est pas exactement ca. Si tu parle de .dmg, se sont des sortes d'isos que tu monte avec tout à l'intérieur. Tu peux déplacer ton dmg et tout sans soucis. C'est pas mal différent de lien symbolique et de répertoire.

    
    Je pensais surtout a l'organisation de l'arborescence, mais apparemment c'est hérité de NeXTStep donc.
    
    

    C'est quoi le problème avec /dev/null ? Il n'y a pas de problème avec /dev/null.

    
    Bah /dev/null existe c'est ça le problème ! il devrais être dans /System/... et /dev ne devrais pas exister, pour que ce soit "propre" !
    
    

    Euh, hu ? Compatible avec ... quoi ? C'est quoi ce problème que tu essaye de pointer ?

    
    Aucun en particulier mais j'imagine que certains programmes doivent être assez perturbés par une arborescence non standard (absence de /proc par exemple), enfin je pense, tous ne sont pas "bien" programmés.

    • [^]Re: Interessant

      Posté par inico (Jabber id, page perso, ) le 04/11/2006 à 18:00. (lien). Évalué à 2.

      Je crois qu'une partie de LSB existe sous forme de liens symbolique caché par un module Kernel.

      --
      "Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..

• [^]Re: Interessant

  Posté par oops (page perso, ) le 04/11/2006 à 10:05. (lien). Évalué à 3.

  >Même si c'est assez pompé sur MacOS !
  
  Sur NeXTStep ( en 1989 ).
  Et MacOSX est construit à partir de NeXSTEP ( OpenSTEP pour être précis )

• [^]Re: Interessant

  Posté par AP () le 07/11/2006 à 10:25. (lien). Évalué à 1.

  MacOS utilise le concept d'appdir qui veut que toute l'application soit contenue dans un répertoire et ce répertoire soit déplaçable à loisir sans empêcher l'application de fonctionner. Avec Gobolinux, une application est toute entière contenue dans un répertoire (exécutables, libs, docs). Supprimer le répertoire supprime bien toute trace de l'application. En revanche, déplacer ledit répertoire est susceptible de poser quelques problèmes...
  
  En fait la force de Gobolinux est d'utiliser une arborescence repensée mais de continuer à offrir "en sous main" l'arborescence Unix standard (cachée par l'entremise d'un module (nommé "gobohide") du noyau), via une astucieuse série de liens logiques. Du coup, les applications comportant trop de références "en dur" ou "non relatives" à des fichiers systèmes ne sont pas dépaysées et n'ont pas besoin d'être retouchées dans leurs sources.
  
  Ce que le site gobolinux ne m'a pas dit (mais peut-être n'ai-je pas tout bien lu), c'est comment les scripts de gestion/maintenance de tous ces liens logiques fonctionnent pour réparer ou supprimer les liens cassés et comment les dépendances sont gérées lors de l'installation d'une nouvelle application. En outre, est-il possible pour un utilisateur lambda d'installer une appli. dans le dossier /Programs ? Je n'ai pas encore de réponse...
  
  En tout cas cette distribution a le grand mérite de remettre en question pas mal de choses, de manière intelligente et argumentée, en cherchant les bons compromis. Je crois que le mieux est d'aller lire la FAQ du site, de télécharger le LiveCD et d'essayer tout ça...