Vu que tout le monde donne son avis, je vais pas me priver :)
Je pense que le fait d'avoir pleins d'exécutables dans /usr/bin ou /usr/X11R6/bin doit être conservé et ce pour une rapidité de la recherche ou de l'autocomplétion chère à tout unixien converti.
Par contre ces exécutables devrait être des liens symboliques vers d'autres exécutables.
Par exemple : /usr/bin/xemacs -> /usr/share/xemacs/bin/xemacs
voir même /usr/bin/xemacs -> /usr/share/X11/editor/xemacs/bin/xemacs
On pourrait ainsi avoir une arborescence très propre et facile à maintenir. Et au pire, on utilise un outil comme "symlinks" pour retrouver les liens morts.
On pourrait de plus ranger les applications par domaines d'utilisation et/ou par couche. xawtv trouverait ainsi sa place dans /usr/share/X11/multimedia/tv/xawtv et aatv dans /usr/share/multimedia/tv/aatv. Dans chaque répertoire de l'application on retrouverait une hiérarchie similaire (/bin, /doc/txt, /doc/html, /img, /sound, ...)
Pour ce qui est des ressources qui n'appartiennent à aucun paquetage (fond d'écrans, sons, documentation générale sur linux,...), on pourrait les mettres dans un répertoire /usr/share/ressources/ tout en conservant une hiérarchie (/sounds, /wallpapers, /doc/system, /doc/devel,...)
On peut ensuite imaginer la même chose dans usr/lib avec des liens vers /usr/lib/multimedia/tv/xawtv/libxawtv.so par exemple.
Par contre pous les applications de maintenance ou lié aux shells, on les laissent dans /sbin (pour la maintenance et l'administration) et /bin car qd on crashe la partition /usr on aurait l'air fin si plus un seul lien ne marche :)
Pour ce qui est de l'utilisation de /opt, je pense qu'elle est à bannir. Premièrement parce que le cas d'utilisation de /opt est très mal définies (gros programmes,...). Et deuxièmement parce que pour l'avoir utilisé sur un Unix, je trouvais ça super chiant de chercher si mon application était dans /op /usr ou /usr/local ;)
Malheureusement, il y a peut-être un problème avec cette solution de lien symbolique. N'y a t-il pas une limite sur le nombre de liens symboliques que Linux ou un de ses système de fichier peut gérer ?
J'aimerais l'avis d'un expert sur cette question.
Pour ce qui est de la gestion de packages par des outils externes (dpkg, rpm, apt-get, urpmi,...), je trouve ça carrément pratique. Surtout autoirpm que je n'arrive plus à faire marcher. Qd on compile un prog, lors du ./configure si une librairie manque il nous propose de l'installer si elle se trouve dans une des sources (cd, ftp,...).
Je pense, que Mosfet n'est pas non plus contre les paquetages : preuve en est de son thême Liquid qu'il fournit en .tgz, .rpm et .deb
Voilà, c'était l'avis d'une moule qui si elle moulait moins et quelle avait le temps et les connaissances pour se faire son propre LFS choissirait cette solution :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
# Liens symboliques
Posté par Infernal Quack (site web personnel) . En réponse à la dépêche Mosfet : Rage against the File System Standard. Évalué à 8.
Je pense que le fait d'avoir pleins d'exécutables dans /usr/bin ou /usr/X11R6/bin doit être conservé et ce pour une rapidité de la recherche ou de l'autocomplétion chère à tout unixien converti.
Par contre ces exécutables devrait être des liens symboliques vers d'autres exécutables.
Par exemple : /usr/bin/xemacs -> /usr/share/xemacs/bin/xemacs
voir même /usr/bin/xemacs -> /usr/share/X11/editor/xemacs/bin/xemacs
On pourrait ainsi avoir une arborescence très propre et facile à maintenir. Et au pire, on utilise un outil comme "symlinks" pour retrouver les liens morts.
On pourrait de plus ranger les applications par domaines d'utilisation et/ou par couche. xawtv trouverait ainsi sa place dans /usr/share/X11/multimedia/tv/xawtv et aatv dans /usr/share/multimedia/tv/aatv. Dans chaque répertoire de l'application on retrouverait une hiérarchie similaire (/bin, /doc/txt, /doc/html, /img, /sound, ...)
Pour ce qui est des ressources qui n'appartiennent à aucun paquetage (fond d'écrans, sons, documentation générale sur linux,...), on pourrait les mettres dans un répertoire /usr/share/ressources/ tout en conservant une hiérarchie (/sounds, /wallpapers, /doc/system, /doc/devel,...)
On peut ensuite imaginer la même chose dans usr/lib avec des liens vers /usr/lib/multimedia/tv/xawtv/libxawtv.so par exemple.
Par contre pous les applications de maintenance ou lié aux shells, on les laissent dans /sbin (pour la maintenance et l'administration) et /bin car qd on crashe la partition /usr on aurait l'air fin si plus un seul lien ne marche :)
Pour ce qui est de l'utilisation de /opt, je pense qu'elle est à bannir. Premièrement parce que le cas d'utilisation de /opt est très mal définies (gros programmes,...). Et deuxièmement parce que pour l'avoir utilisé sur un Unix, je trouvais ça super chiant de chercher si mon application était dans /op /usr ou /usr/local ;)
Malheureusement, il y a peut-être un problème avec cette solution de lien symbolique. N'y a t-il pas une limite sur le nombre de liens symboliques que Linux ou un de ses système de fichier peut gérer ?
J'aimerais l'avis d'un expert sur cette question.
Pour ce qui est de la gestion de packages par des outils externes (dpkg, rpm, apt-get, urpmi,...), je trouve ça carrément pratique. Surtout autoirpm que je n'arrive plus à faire marcher. Qd on compile un prog, lors du ./configure si une librairie manque il nous propose de l'installer si elle se trouve dans une des sources (cd, ftp,...).
Je pense, que Mosfet n'est pas non plus contre les paquetages : preuve en est de son thême Liquid qu'il fournit en .tgz, .rpm et .deb
Voilà, c'était l'avis d'une moule qui si elle moulait moins et quelle avait le temps et les connaissances pour se faire son propre LFS choissirait cette solution :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire