[FHS] question sur /lib

[nlu_]

bonjour,

la dernière mise à jour de mon install a porté le contenu de lib dans /usr/lib
Je me demandais ce qui avait motivé cette transformation.

J'ai la même question pour /media qui se retrouve maintenant dans /run/media et qui a rallongé le chemin d'acces à un device amovible ?

est-ce la préparation d'arch à l'utisation unique de systemd ?

Si quelqu'un pouvais éclairer ma modeste lanterne

Merci.

[chipster]

Toujours faire un petit tour sur le site .fr soit, si l'info ne s'y trouve pas, le site.org.
Ta réponse se trouve donc ici : http://archlinux.fr/news/le-repertoire- ... symbolique


[edit] Si jamais tu as des soucis pour la mise à jour, il existe un post ici : http://forums.archlinux.fr/topic11420.html

[FoolEcho]

... m'a fallu me replonger dans les archives pour les sources...

la dernière mise à jour de mon install a porté le contenu de lib dans /usr/lib
Je me demandais ce qui avait motivé cette transformation.

En résumé, c'est plus "KISS" (et techniquement, je crois que l'apport de kmod a poussé dans ce sens).
http://mailman.archlinux.org/pipermail/ ... 22625.html
(et il y a des articles courant juillet pour suivre cette transition: http://mailman.archlinux.org/pipermail/ ... 23178.html , http://mailman.archlinux.org/pipermail/ ... 23200.html, http://mailman.archlinux.org/pipermail/ ... 23207.html)

est-ce la préparation d'arch à l'utisation unique de systemd ?

Utilisation unique, pas sûr... mais pas impossible qu'Arch y vienne. C'est un sujet à débattre en tous cas. Rien à voir avec cette histoire de liens symboliques en tous cas.
Voir http://mailman.archlinux.org/pipermail/ ... 22803.html

[chipster]

Oula, j'ai complet répondu à coté moi. Désolé

[nlu_]

... m'a fallu me replonger dans les archives pour les sources...

la dernière mise à jour de mon install a porté le contenu de lib dans /usr/lib
Je me demandais ce qui avait motivé cette transformation.

En résumé, c'est plus "KISS" (et techniquement, je crois que l'apport de kmod a poussé dans ce sens).
http://mailman.archlinux.org/pipermail/ ... 22625.html
(et il y a des articles courant juillet pour suivre cette transition: http://mailman.archlinux.org/pipermail/ ... 23178.html , http://mailman.archlinux.org/pipermail/ ... 23200.html, http://mailman.archlinux.org/pipermail/ ... 23207.html)

est-ce la préparation d'arch à l'utisation unique de systemd ?

Utilisation unique, pas sûr... mais pas impossible qu'Arch y vienne. C'est un sujet à débattre en tous cas. Rien à voir avec cette histoire de liens symboliques en tous cas.
Voir http://mailman.archlinux.org/pipermail/ ... 22803.html

Merci pour les liens.

Personnellement je ne vois pas ce qu'il y a de KISS à mélanger les repertoires.
Mais bon je ne lis pas assez l'anglais, et ne suis pas expert en demarrage systeme pour comprendre toutes les subtilités de la chose.
j'ai toujours pensé que /lib était reservé au systeme comme /bin et /sbin et etaient necessaires pour le boot du systeme et que le contenu de /usr etait le reste des applis en share

Comme de passer par exemple /media/samsung à /run/media/toto/samsung c'est pas genant pour les specialistes du clickodrome je trouve ca genant pour mes doigts en cli, d'ailleurs à quoi sert le repertoire /media maintenant ?

quant a systemd je trouve que cela va a l'encontre de la philosophie UNIX. J'ai lu un article sur linuxfr, d'un autre coté, il est vrai que je ne vois que mes besoins.

[FoolEcho]

L'argument principal de l'auteur est d'éviter de dupliquer les emplacements des bibliothèques et des binaires, c'est donc plus KISS dans la mesure... où tout est fourré au même endroit donc c'est plus facile à retrouver (mais évidemment on pourrait dire que c'est plus KISS de savoir précisément où se trouve tel ou tel truc). «Historiquement», c'est aussi parce qu'il fallait distinguer les éléments nécessaires à l'initramfs du reste utilisable une fois le système lancé (d'où la vision que tu as -- qu'on a tous je suppose -- des /boot, /bin etc.)... mais maintenant /usr est monté depuis l'initramfs, donc ça ne justifie plus vraiment d'être aussi rigide.

D'où le contre-argument du "pourquoi ne pas tout mettre à la racine tant qu'on y est ?" ... parce que ça fait moins le bazar quand même (faut quand même conserver la posssibilité d'avoir des partitions dédiées).
L'autre chose concerne la fusion de bin/sbin, car on colle de toutes manières dans le PATH des utilisateurs les deux (vu que les droits d'utilisation font la différence)... mais là, c'est un peu plus problématique à réaliser.

D'ailleurs Dan McGee a d'ailleurs fait remarquer que c'était se casser le c** (refaire les paquets) pour pas grand-chose (avis que je partage même si on s'en fout ). Il a complété plus loin en disant que c'était de toutes manières déplacer d'un mauvais emplacement à un autre, personne n'étant capable de dire avec certitude si telle ou telle chose devrait aller à tel ou tel endroit (avec exemples à l'appui: on peut effectivement avoir des binaires ou des fichiers de configuration qui se trimbalent dans lib ).
Je pourrais résumer la pensée de ce fil en disant: on bouge tout de /lib à /usr/lib parce qu'au final on peut et que ça ne change pas grand-chose si c'est bien fait (et vu qu'avec le lien symbolique, on s'épargne le casse-tête des applications qui cherchent dans /lib...).

Pour ce qui me concerne, à part réveiller les Archers lors de cette mise à jour sur le forum ainsi que les mainteneurs sur Aur, je suis assez d'accord avec toi, ça n'a guère d'intérêt, vu qu'au final, pour rester compatible avec d'autres distributions/applications, on conserve la même architecture via les liens symboliques (ceci étant, je fais du développement objet et pas du tout de système, donc «casser» ou refaire un truc et constater que tout fonctionne quand même me botte toujours... sauf que là, ils sont petits joueurs avec le lien symbolique ^^). Ah si tiens, comme beaucoup, j'ai pu virer des /lib/modules dont je ne soupçonnais même plus l'existence .

Pour moi, ça ressemble au va-et-vient centralisation/décentralisation de l'état selon les époques. Il suffira de quelqu'un d'assez convaincant dans le futur pour rechanger ça.

Pour systemd, je ne peux rien te dire, je ne l'utilise pas non plus. Je pense qu'il faudra qu'il fasse ces preuves avant de s'imposer même s'il gagne du terrain.