FHS 2.2

Posté par  (site web personnel) . Modéré par Yann Hirou.
Étiquettes :
0
6
sept.
2001
Linux
L'ensemble de tests du FHS 2.2 (FileSystem Hierarchy Standard) est sorti.
L'état d'avancement, les nouvelles releases de la LSB et du FHS vont-ils accélérer le rapprochement des distribs vers ces standards ?

Aller plus loin

  • # De l'utilité du FHS

    Posté par  . Évalué à 10.

    Ca serait pas mal que toutes les distribs s'acharnent à respecter le FHS. L'un des principaux griefs faits à Linux (par les partisans de Windows principalement) est que Linux reproduit les mêmes erreurs qu'Unix par le passé, en partant dans des directiosn opposées.

    Le FHS permet de limiter les différences entre les distributions et donc de faciliter l'usage de Linux, toutes distros confondues... Et, on peut toujours réver, peut être qu'en rapprochant les distribs, les utilisateurs pedraient moins de temps à troller sur les avantages de leur distro préférée et plus de temps à coder/documenter/traduire ! :-)

    • [^] # Re: De l'utilité du FHS

      Posté par  . Évalué à 2.

      Je pense que c'est déjà le cas pour la plupart des grosses:
      Debian et Suse y ont toujours collé de très près.
      Mandrake a à plusieurs reprises affirmé vouloir s'y plier aussi.
      RedHat, sans doute aussi, vu qu'il s'agit d'une copie de Mandrake

      • [^] # Re: De l'utilité du FHS

        Posté par  (site web personnel) . Évalué à 2.

        Bah justement, j'ai aussi posté la news sur MandrakeForum ( http://www.mandrakeforum.com(...) ), avec espoir d'y être moderé, tout en posant la question du respect du FHS 2.2 pour la prochaine mdk8.1 (elle passe en beta 3 bientôt, dernière beta avant release officielle).

        • [^] # Re: De l'utilité du FHS

          Posté par  . Évalué à 6.

          Le problème, c'est que ça ne dépend pas uniquement de ceux qui font la distribution. Si je fais un programme dans lequel il y a en dur un nom de fichier de configuration qui est "/usr/etc/mon_prog/config", Mandrake n'y peut pas grand chose.

          Le minimum c'est d'avoir des switches à la compil pour paramétrer tout (mais ça donne du boulot pour faire la distribution) et idéalement, ca devrait déjà être conforme dans le soft dès le départ.

          • [^] # Re: De l'utilité du FHS

            Posté par  . Évalué à 1.

            Ben, si t'as les sources du soft, tu peux modifier.

            Et puis, il y a eu pas mal de cas ou c'était bien les auteurs de la distrib qui ont tout modifié/déplacé.

          • [^] # Re: De l'utilité du FHS

            Posté par  . Évalué à 5.

            Si je fais un programme dans lequel il y a en dur un nom de fichier de configuration qui est "/usr/etc/mon_prog/config", Mandrake n'y peut pas grand chose.

            Désolé mais le travail d'une distribution, c'est pas seulement de faire un recueil de programmes et de les mettre sur un CD. Il faut vérifier leur conformité à la politique de la distrib. Ce que tu décris est tout simplement un bug (vis-à-vis des consignes de la politique). Donc soit le logiciel n'est pas libre, et il n'est pas intégrable dans la distrib (de toutes façons, le fait d'etre libre est généralement exigé dans la politique), soit le logiciel est libre, auquel cas c'est à la distrib de le modifier comme il faut (l'idéal : en coopération avec le développeur).
            C'est bien la distribution qui est responsable de ce qu'elle incorpore.

          • [^] # Re: De l'utilité du FHS

            Posté par  . Évalué à 0.

            Le problème, c'est que ça ne dépend pas uniquement de ceux qui font la distribution.

            Les distributions ne se gènent pas pour modifier ce genre de chose. Il n'y a qu'a prendre un src.rpm et aller jetter un coup d'oeil dedans.

            L'expérience que j'en ai est qu'il y a très souvent un patch qui est appliqué sur les sources et qui sert à modifier les chemins de divers fichiers sur le FS pour correspondre à la norme de la distribution.

            (Faire " rpm2cpio machin.src.rpm | cpio -i " puis " less *.patch ")

        • [^] # Une réponse vue sur mandrakeforum...

          Posté par  . Évalué à 0.

          Hi, I was just wondering.. shouldn't mandrake take the lead and conform to the standards those good guys with some noble thoughts are coming up with!
          For eg. FSH says that all media should be mounted on /media.. which could really be more logical since most of the newbies actually don't know what "mount" means anyway.. and its really not a big task to do! Afterall someone had to create a standard and now that its done, we all should follow it!
          What do other LM users feel about these standards?
          sarang

          Answer: Official policy of Mandrakesoft is "Linux-Mandrake" will adhere to LSB and FSH in particular". However, we are talking about "standard to be" here, i.e. about a moving target.

          Take "/media" as an example. This directory popped up for the first time in FSH 2.2, which is currently in "public beta reviewing" phase. "Public beta reviewing" means that it could still disapear from final version of the document, or be renamed. (For instance, in my opinion, "/removable" would be a better name.)

          Traditionally "/mnt" has been used for this purpose, and rushing to switch to "/media" only because it MIGHT become a new standard does not look like a good idea to me. Besides, we need to leave something for LM 8.1, you know.... .-)

      • [^] # Re: De l'utilité du FHS

        Posté par  . Évalué à 2.

        RH, une copie de MDK, c'est la première fois qu'on me l'a fait celle là ! :))

        Les standards, faut aussi qu'ils soient établis pour etre suivi. La LSB, la dernière fois que je me suis penché dessus, c'était pas vraiment ça...

        • [^] # Re: De l'utilité du FHS

          Posté par  . Évalué à 6.

          >RH, une copie de MDK, c'est la première fois qu'on me l'a fait celle là ! :))

          En effet, cher ami, comme vous le notez si justement, j'ai cherché par ce biais à introduire une note humoristique et légère dans mon argumentation, afin de détendre le lecteur tout en ne nuisant pas à la compréhension du fond de mon propos.

          • [^] # Re: De l'utilité du FHS

            Posté par  . Évalué à 1.

            en gros tu trolles , non ?

            • [^] # Re: De l'utilité du FHS

              Posté par  . Évalué à 0.

              non, je ne crois pas qu'il troll
              troller est l art de piquer du monde au vif pour les faire réagir.

              ça, c comme si je te disais que Micheal Shumacher est le champion du monde d'échec

              c tellement évident que faut vraiment être d'un esprit fermé incroyable pour prendre moindrement ça au sérieux

              • [^] # Re: De l'utilité du FHS

                Posté par  . Évalué à 2.

                c'est honteux! je m'insurge! Tout le monde sait que le champion du monde d'échec WBC est Jean Alesi! Des dizaines de courses, et un seul succès! Mais il est très sérieusement menacé par Olivier Panis...

                hop -1

      • [^] # Re: De l'utilité du FHS

        Posté par  . Évalué à 2.

        SuSE est conforme a la LSB ???

        SuSE a viré son gros fichier genre registry ou LSB est tres laxiste ????

        • [^] # Re: De l'utilité du FHS

          Posté par  . Évalué à 0.

          regarde le lien sur le vieux test:
          http://www.linuxbase.org/test/results/index.html(...)
          la suse 7.0 y est la meilleure distro.

          (attention, ce vieux test est 1- réalisé sur une préversion de la LSB et 2- sujet à des critiques pertinentes de Debian (Wickert Akkerman) quant aux résultats de woody)

          • [^] # Re: De l'utilité du FHS

            Posté par  . Évalué à 1.

            Oui, j'avais vu passer ce test, et j'avais aussi lu les commentaires de l'équipe Debian à l'époque.....

            Ca ressemblait quand meme un peu à un test pipeau genre "foutage de gueule", je trouve...

        • [^] # Re: De l'utilité du FHS

          Posté par  . Évalué à 0.

          > SuSE est conforme a la LSB ???
          Farpaitement. SuSE fait partie des contributeurs.

          > SuSE a viré son gros fichier genre registry ou LSB est tres laxiste ????
          /etc/rc.config ? En quoi cela empêche-t-il la conformité à la LSB ?
          Il est très pratique, le gros fichier, pour ceux qui n'ont aucune envie de
          se taper 200 fichiers de config à la main. YaST + SuSEconfig,
          ce n'est pas pire qu'un linuxconf ou un webmin.

          Et s'il t'embête, le gros fichier, tu n'as qu'une variable à mettre à jour dedans:
          ENABLE_SUSECONFIG=no
          et tu pourra mettre les mains dans le cambouis tout seul comme un grand.

          • [^] # Re: De l'utilité du FHS

            Posté par  . Évalué à 1.

            > Et s'il t'embête, le gros fichier, tu n'as qu'une variable à mettre à jour dedans:
            > ENABLE_SUSECONFIG=no
            > et tu pourra mettre les mains dans le cambouis tout seul comme un grand.

            C'est vrai ??

            Ben si j'avais su ca à l'époque, je serais peut etre resté a la SuSE, alors....

            Mais bon, pour maintenant, comme la Debian aussi est conforme :-)

    • [^] # Re: De l'utilité du FHS

      Posté par  . Évalué à 3.

      La question que je me pose, c'est dans quelle mesure les distributions Linux commerciales (caldera, redhat, suse, mandrake,...) vont suivre ces standards.
      Prenons l'exemple de Debian et Mandrake.
      Si ces deux distributions suivent le LSB et le FHS, tout paquetage mandrake devrait etre installable sans aucun probleme sur debian (eventuellement via alien) et surtout y etre completement integre (ne pas avoir a refaire les path, etc...), et reciproquement.
      Pourquoi alors est-ce que j'opterais pour une mandrake ?
      Si je ne m'abuses, aujourd'hui les gens prennent une mandrake principalement pour ses outils d'administration, et son installation facile.
      A partir du moment ou ces outils sont portables sans aucun cout additionnel ailleurs, j'ai du mal a voir comment les societes commerciales peuvent envisager sereinement l'avenir... A moins de faire 90% de service et 10% de vente de boites.

      Des gens directement concernes (Mandrake par exemple) pour repondre ?

      • [^] # Re: De l'utilité du FHS

        Posté par  . Évalué à -3.

        A ton avis pourquoi IBM, Compaq ou autres s'interessent pas a Mandrake ?

        Parce qu'elle ne respecte pas les standards et que , par soucis de cohesion, on ne veut pas la rendre trop populaire !

        • [^] # Re: De l'utilité du FHS

          Posté par  . Évalué à 1.

          Elle est belle celle la.
          En revanche la SuSe elle respecte les standards, surtout sur les parcs de 5700 serveurs...

          On te reconnaît à 10 bornes, mon gars.

          Vu la qualité de ton post je sens que tu dois bien être au courant des stratégies de IBM et Compaq, et des "standards" que Mandrake "ne respecte pas".

          • [^] # Reponse d'un utilisateur de SuSE !

            Posté par  . Évalué à -1.

            Bon, je viens pas relancer de polemiques, mais j'ai obtenu la derniere SuSE 7.2 et je peux te dire, faute peut etre d'etre 100% standard, elle permet aux 'VRAI' debutant d'avoir un systeme operationnel.

            Exemples :
            - J'ai acheté la Mandrake 7.2 à l'epoque, j'ai jamais reussi a configurer mon scanner USB , mon Joystick , et j'ai jamais reussi a utiliser ma carte son. Dans la doc de Mandrake y a bien un truc sur les cartes sons mais rien sur le Joystick ni le Scanner USB !

            Dans le pack SuSE, ils nous expliquent NOIR SUR BLANC les etapes pour configurer mon modem, ma carte son, mon Joystick, mon scanner, comment automatiser ceci (c'est a dire la prise en compte du matos des le demarrage). Y a meme un bouquin sur les applications, et des explications sur le reseau et la configuration d'un serveur local (je m'en fou ça m'interesse pas).

            Alors Mandrake pour debutant, je l'ai entendu ça, mais si c'est juste pour voir un beau Bureau et faire mumuse avec Star Office ça m'interesse pas : Je veux un systeme Linux fiable et performant , et je veux voir tout ce que Windows sait faire !

            SuSE n'est peut etre pas la meilleure mais c'est au moins CELLE qui se soucie le plus pour les debutants qui jamais touché à Linux !

        • [^] # Re: De l'utilité du FHS

          Posté par  . Évalué à 2.

          Quand je disais mandrake, j'aurais pu dire suse, ou redhat.
          Je pense qu'il y a plus de lecteurs de dlfp bossant chez mandrake que chez redhat ou suse, donc je pense que c'est le meilleur exemple pour avoir une reponse directe des interesses...

          • [^] # Re: De l'utilité du FHS

            Posté par  . Évalué à 1.

            c clair il suffit de voir les stats

          • [^] # Re: Rions un peu : Aujourd'hui, l'attitude de SuSe vis à vis de DFLP

            Posté par  . Évalué à 1.

            Mais si il y a un gars de chez SuSe qui lit dflp.

            Bon, il poste systématiquement en anonyme pour dire que depuis qu'il a installé SuSe sur les 17 millions de machines de sa multinationale, les femmes le regardent à nouveau, il ne perd plus ses cheveux et il s'est acheté une BM et a gagné un abonnement Linux Mag grâce à DLFP, mais il est bien là.

            Je crois que son travail consiste à ancrer dans la tête des gens que "la SuSe c'est bien oui la SuSe c'est bien, Mandrake va couler, IBM, Compaq, Dell
            et ma crémière pensent que Mandrake ne respecte pas les standards". Un boulot qui serait marrant s'il était un chouia plus discret...

          • [^] # Re: De l'utilité du FHS

            Posté par  . Évalué à 3.

            Dans la mesure ou les logiciels libres produits par mdk sont libre, on peut sans problème les porter sous d'autres distrib. Facile logiquement d'installer drakfont bidule sur debian, à partir du source.

            Maintenant, la MDK, c'est aussi des trucs comme l'installation graphique logiquement plus simple que l'install d'une debian.

            Et ton argument se retourne très bien : si apt-get est installable sur RH, MDK, y'aurait-il autant de gens qui passeraient sous Debian ?

            D'ailleurs, concernant apt-get, je m'étonne que ce logiciel n'ai été envisagé que pour fonctionner avec dkpg ... alors qu'un système de greffons aurait pu le rendre compatible rpm slp ...

            Alors ?

            • [^] # RPM-Get?

              Posté par  . Évalué à 1.

              Pour la comptaibilité avec les RPM y'a ca,ca répond à tes critères?
              Maintenant je sais pas si c'est super utilisable actuellement.

              cf:http://freshmeat.net/projects/rpm-get(...)

              • [^] # Re: RPM-Get?

                Posté par  . Évalué à 3.

                Non, je ne parles de pas de clonage de apt-get.

                Je parles d'apt-get. Pourquoi apt-get ne pourrait-il pas fonctionner avec RPM tout comme il fonctionne avec apt-get ?
                Des options qui ne portent pas le meme nom ? Avec un systeme de greffons, ça ne pose aucun problème. Tout comme ça ne pose pas de problème d'utiliser dacode avec n'importe quel type de serveur SQL, puisqu'on peut écrire un greffon.

                Je ne comprend pas que ça n'ait jamais été envisagé :
                - un désacord de debian ne désirant pas partager son principal attrait (et refusant d'instaurer un système de greffons, mettant dkpg au meme rang que rpm) ??
                - un choix délibéré de RH désirant rentabiliser son système de mises à jour payante ??

                Quoi qu'il en soit, ça ne profite pas aux uilisateurs.

                Et pourquoi écrire un rpm-get imparfait alors qu'un apt-get GPL stable existe déjà ?

                Sinon, il existe le urpmi de Mandrake.
                Seulement, j'ai un problème avec MDK :
                qu'ils découpent leurs RPMS différement de toutes les autres distribs (genre pour le paquet gtk+ qu'on trouve un peu partout : on a le droit à un gtk+mdk (attention, je parle du nom du paquet, pas du nom de version, c'est à dire qu'au lieu d'avoir un gtk+-1.2.0-1.i386.rpm ou éventuellement gtk+-1.2.0-1mdk.i586.rpm, on se prend un gtk+mdk-1.2.0-1mdk.i586.rpm !! )), c'est leur problème. Je ne vois pas l'interet. Maintenant, en voulant installer drakfont que j'ai pu tester sur une MDK (et trouvé pratique), j'ai téléchargé le paquet MDK... Et surprise : grace aux noms de paquets non standards (qui ne correspondent ni à ceux donnés par les auteurs de logiciels ni les autres distribs), y'a des dépendances qui chient dans la colle partout : alors qu'en fait, toutes les dépendances sont ok.. mais n'ont pas le meme nom.
                Et c'est là que je me dis : popol, le urpmi, c'est pas demain que tu va l'utiliser, parti comme ça.

                Je vois pas trop où MDK veut en venir avec ces methodes. Enfin bon, une fois de plus, en tant qu'utilisateur, je ne suis pas aidé..

                C'est pourtant pas si compliqué dans le fond.. Il existe ce sacré bondieu d'apt-get... Seulement, on aurait presque l'impression que ça arrange tout le monde que ça reste limité à debian... enfin tout le monde, sauf les utilisateurs...

                • [^] # Re: RPM-Get?

                  Posté par  . Évalué à 1.

                  Oulalalal mon grand tu te trompes il ya bien
                  un gtk+mdk mais ce n est pas LE Gtk

                  la preuve : rpm -qip libgtk+mdk donne
                  Name : libgtk+mdk0.1_6 Relocations: (not relocateable)
                  Version : 0.1.6 Vendor: MandrakeSoft
                  Release : 4mdk Build Date: lun 16 jui 2001 16:51:11 CEST
                  Install date: (not installed) Build Host: ke.mandrakesoft.com
                  Group : System/Libraries Source RPM: gtk+mdk-0.1.6-4mdk.src.rpm
                  Size : 251257 License: GPL
                  Packager : DindinX <odin@mandrakesoft.com>
                  Summary : Mandrake specific GTK+ Widgets
                  Description :
                  This package contains the library needed to run programs dynamically
                  linked with libgtk+mdk.


                  ce sont des widgets suplementaires

                  le "vrai" gtk s appelle libgtk+1.x

                  tu remarqueras que mandrake applique la meme politique de nom a ses packages

      • [^] # Re: De l'utilité du FHS

        Posté par  (site web personnel) . Évalué à 1.

        Ils font des outils pas libre (yast), ils mettent les outils que le CD, etc.

        Bref, pour avoir le droit d'obtenir les outils faut payer ;)

      • [^] # Re: De l'utilité du FHS

        Posté par  (site web personnel) . Évalué à 2.

        Meme si deux distributions suivent à la lettre le LSB, ce n'est pas pour autant que les paquetages marcheront de l'une à l'autre, il y a trop de versions de bibliothèques qui se promènent, et le LSB ne résoud pas les problèmes de conflit/dépendances de versions.

  • # Une question sur la FHS: ou se met KDE par exemple?

    Posté par  . Évalué à 0.

    Juste une petite question "innocente"..

    Non je dis ca parce que quand j'ai lu la FHS, je l'ai trouve tellement bien faite (ce n'etait pas la 2.2 mais une vieille version) que j'etais incapable de repondre a ca..

    Bah, c'etait juste pour dire que la hierarchie de fichier sous Unix c'est toujours le b... (d'ailleurs le Nemeth "UNIX System Administration Handbook" est d'accord!)

    • [^] # Re: Une question sur la FHS: ou se met KDE par exemple?

      Posté par  . Évalué à 2.

      Bah, c'etait juste pour dire que la hierarchie de fichier sous Unix c'est toujours le b...

      C'est peut être le bordel, mais ca reste le système où c'est moins le bordel que sur n'importe quel autre OS qu'il m'ai été donné d'essayer (Win, Be, Mac et Un*x).

      Sur Windows le concept de C: D: et compagnie m'énerve profondément. Selon toute logique, tout devrait aller sur le seul disque C: ("Mes Documents", "Program Files", "Windows\System", je crois même quil y a "Mes sons" ou un truc dans le genre).

      Bref "c'est le bordel partout, mais y'a des OS ou c'est plus le bordel qu'ailleurs" (c)TM

      PS : KDE, selon le FHS doit se mettre dans /opt (AMHA)

    • [^] # Re: Une question sur la FHS: ou se met KDE par exemple?

      Posté par  . Évalué à 2.

      Il y a une version postscript (et txt, et dvi) en français de la FHS ici:
      ftp://ftp.minet.net/pub/local/FHS/(...)

      En la lisant, je pense que KDE doit se trouver dans l'arborescence de X11 (/etc/X11, /usr/X11R6)

      • [^] # CQFD :-)

        Posté par  . Évalué à 1.

        En lisant la FHS, j'avais été incapable de me décider entre /opt et /usr/local..

        Je me suis pris un -1, c'est peut-etre justifié mais si la référence en matière d'administration systeme (le Nemeth) dits que le systeme de fichier Unix est un "mess", c'est qu'il y a peut-etre un grain de vérité la-dessous.

        reno

        PS:
        je n'ai jamais dit que sous Windows c'était mieux, C:,A: beurk!

      • [^] # Re: Une question sur la FHS: ou se met KDE par exemple?

        Posté par  . Évalué à -1.

        Ce qu'il faudrait c'est un fichier de config qui recense les emplacements des composants suceptibles d'etres utilisés pas d'autres. Je ne sais pas s'il y a un équivalent de LANANA pour les noms de logiciels/packages, mais ça pourrait très bien se faire. Tous les softs sauraient alors si KDE est installé ou pas, et s'il est ici ou là. Le FHS peut lever des ambiguïtés, mais de nouvelles apparaîtront sans cesse, c'est ça le problème. Une fois que le répertoire de base est connu, le FHS pourrait donner des indications tel que "tout programme installé là doit mettre ses libs ici et ses fichiers de config ici".
        Un simple fichier texte, associations nom/répertoire, c'est lisible on ne tombe pas dans l'excès "base de registres".

    • [^] # Re: Une question sur la FHS: ou se met KDE par exemple?

      Posté par  . Évalué à 2.

      hehe, bonne question. Deux réponses ci-dessus, et déjà deux avis différents...
      SuSE met toujours KDE dans /opt (ainsi que Gnome, Netscape, ...)
      Les autres distributions majeures ont intégré KDE dans l'arborescence /usr

      D'après le FHS, /opt est pour les "add-ons".
      Donc du point de vue de la distrib, les softs intégrés vont dans /usr.
      On réserve /usr/local aux bricolages maison de l'admin, et /opt
      pour les gros paquets cohérents (genre StarOffice, Oracle, DB2, ...).
      Note que le FHS prévoit /opt/{bin,lib,man,...} pour les bricolages locaux sur ces paquets.

      • [^] # Re: Une question sur la FHS: ou se met KDE par exemple?

        Posté par  . Évalué à 1.

        D'après la FHS, /opt n'est là que parce que ça existe traditionnellement sur les Unices ... Il est conseillé de n'y mettre que les logiciels qui ne pourraient pas fonctionner ailleurs (chemins en dur) ou des logiciels optionnels (donc pas dans le PATH par défaut). Maintenant, toujours d'après la FHS, /opt/{bin,lib,man,...} n'est qu'un bricolage facultatif pour les administrateurs qui n'ont pas trop envie de se casser la tête ! Sur mes machines, ne vont dans /opt que les logiciels qui ne peuvent pas coexister : différentes machines virtuelles Java, des versions différentes d'extensions standard ... Un simple script en perl+bash me modifie les variables d'environnement pour choisir parmi ces versions.

        Personnellement, je verrais plutôt KDE (ou GNOME, ne soyons pas sectaires ;-)) dans /usr parce qu'il est en général inclu dans la distribution utilisée. C'est alors au système de paquets de la distribution de gérer tous les fichiers qui doivent aller ailleurs (/etc, /dev, /tmp?).

        En revanche, si la distribution ne contient pas de paquet pour le logiciel, alors il doit aller dans /usr/local (contrairement à ce que disent les magazines : "faites simplement ./configure && make && make install", /usr étant souvent la destination par défaut).

        Mieux, les logiciels compilés par l'utilisateur, ou installés depuis des binaires bruts (hors paquet) seraient encore mieux dans /usr/local/stow. Ensuite, un petit stow nom_du_répertoire et hop plein de liens sont créé dans les sous répertoires d'/usr/local.

        On ne veut plus du logiciel, un petit stow --delete nom_du_répertoire && rm -rf nom_du_répertoire et il disparait sans laisser de trace ... Mais dans ce cas, il ne faut pas oublier un ./configure --prefix=/usr/local/stow/nom_du_répertoire.

        Page de stow sur freshmeat : http://freshmeat.net/projects/gnustow/(...)
        Homepage de stow : http://www.gnu.org/software/stow/(...)
        Téléchargement : ftp://ftp.gnu.org/gnu/stow/(...)
        stow nécessite perl 4 ou 5 pour fonctionner.

        • [^] # Re: Une question sur la FHS: ou se met KDE par exemple?

          Posté par  . Évalué à 2.

          En revanche, si la distribution ne contient pas de paquet pour le logiciel, alors il doit aller dans /usr/local (contrairement à ce que disent les magazines : "faites simplement ./configure && make && make install", /usr étant souvent la destination par défaut).

          Non, dans la tres grande majorite des cas, /usr/local est le prefix par defaut. Les seuls dont ce n'est pas le cas sont des softs tres proches du systeme comme la glibc ou quelques autres.

    • [^] # Re: Une question sur la FHS: ou se met KDE par exemple?

      Posté par  . Évalué à 0.

      Je ne retrouve plus le lien, mais Thomas Leonard (l'auteur de ROX) avait écrit un papier à ce sujet en préconisant les Applications Directories.

      Au moins pour les applications utilisateurs, ce systeme (qui consiste, je le rappelle, a réserver UN répertoire par application) permttrait d'avoir un système très propre.
      Sans compter que, au moins pour ces applications là, le probleme des packages serait fortement simplifié: Un simple tgz a mettre dans /usr/apps (ou autre) qui se compile tout seul quand tu l'execute pour la premiere fois... le kif quoi!

      • [^] # Re: Une question sur la FHS: ou se met KDE par exemple?

        Posté par  . Évalué à 0.

        Comme c:\program files\ quoi.

        C'est mon path qui va etre beau avec ca.

        Quand au systeme tres propre, je ne voit pas en toi toto2, utilisant toto1, ca changerais le fait que si je vire toto1, toto2 va pas etre content.

        • [^] # Re: Une question sur la FHS: ou se met KDE par exemple?

          Posté par  . Évalué à 1.

          Pas tout à fait comme c:\progra~1, en ce sens que Thomas propose un structure bien définie pour ces répertoires (inspirée du classique /bin /etc /src...).
          Ainsi effectivement les applications "End-user" (et à priori seulement celles la) seront toutes regroupées dans un seul (où plusieurs, en fait...) répertoires "sensibles".
          L'énorme avantage sur "program files" est que chaque application est contient ses propres sources, et peut donc se compiler toute seule si il n'y a pas de binaire disponible (ou un binaire dépendant d'une autre plateforme). En plus de cela, comme je le disais plus haut, en structurant convenablement le contenu de ces répertoires, on évite en grande partie le gros bordel de "certains répertoires" de nos cheres fat32.

          Après tout RiscOS marche très bien comme cela...

Suivre le flux des commentaires

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