On 07/31/2011 05:23 PM, Michał Górny wrote: > On Sat, 30 Jul 2011 16:55:23 +0300 > Samuli Suominen <ssuomi...@gentoo.org> wrote: > >> I dislike the IUSE="+static" some packages are currently doing to >> workaround this, instead of moving the needed shared libs to / >> >> I dislike the idea of pciutils and usbutils database(s) in >> non-standard location in / to keep udev working >> >> I dislike the idea of moving libglib-2.0, libdbus-1, libdbus-glib-1, >> and couple of dozen more libs to / >> >> I dislike the idea of maintaining and keeping track of the files in / >> using files from /usr. Does any of the PMs have check for this, like >> NEEDED entries? I can imagine this getting past the maintainers easily >> otherwise >> >> Most likely still not seeing the full picture here, and just >> scratching the surface... >> Despite that, I don't have any strong opinion on any of this, just >> need to know if I should start moving the files over > > Honestly, I'd rather see system libs and apps being moved to /usr > rather than the opposite. IMO the benefit of getting a clear tree is > greater than benefits of having separate fs for 'system' and > 'non-system' packages which actually tend to randomly depend one on > another.
that's my impression now too since nobody has managed to provide useful case for separate /usr, or they have been very vague like adding 1+1 on / and /usr filesystem sizes and counting the risk of corrupted filesystem from that (one word: backup) and even then they can go with dracut and have the initramfs mount the /usr before init dracut with it's externsive modules covers the other mentioned cases too so pursuing for getting rid of shared/static -workarounds and / files depending on /usr files constistency not to mention avoiding moving a lot of files to / for pursuing that otherwise this is starting to look good: http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr > > What's the point of having shared /usr if you need to keep /bin, /lib, > /sbin in sync anyway? And considering the above, the number of files to > keep separate & synced is growing, and thus our potential / gets bigger > and bigger. >
