On Dec 14, 2015 12:12 AM, "DJ Lucas" <[email protected]> wrote: > > In section 6.5.1, ran across these while digging intothe merged /usr for systemd. > > The FHS also stipulates the existence of|/usr/local/games|and|/usr/share/games|. > > This is not entirely true. /usr/share/games is listed as optional now (though it might be required for games in BLFS). > http://refspecs.linuxfoundation.org/FHS_3.0/fhs.html#specificOptions15 > Add a comma after "/usr/local/games" and append "if the corresponding subsystem is installed." Maybe a link to BLFS if it is required, or just exclude it? > > Additionally... > >The FHS is not precise as to the structure of the|/usr/local/share|subdirectory, >> >> so we create only the directories that are needed. > > Actually, it now says specifically that it should be the same as /usr/share. > http://refspecs.linuxfoundation.org/FHS_3.0/fhs.html#requirements10 > > As to what I was actually looking for tonight, any particular reason that the /usr merge has not been revisited inthe systemd book? I still like the idea of separate /usr in the main book, there are quite a few important concepts to be learned bykeeping them separate. I believe (IIRC) it was omitted originally due to FHS 2.3. After review, I am merging locally. I figured I'd bring it up here too, in case there is any interest in revisiting it. > > Looking at http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ I see specifically: > > Note that this page discusses a topic that is actually independent of systemd. >> >> systemd supports both systems with split and with merged /usr, and the /usr >> merge also makes sense for systemd-less systems. That said we want to encourage >> distributions adopting systemd to also adopt the /usr merge. > > > I recall some horror stories in the past, but have zero evidence of that. My rationaleis simply that the systemd developers "encourage" it, I know first hand that it's easier, and the FHS does specifically allow this (without actually recommending it) now: > From http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s02.html >> >> >> The following directories, or symbolic links to directories, are required > > in /. >> >> > > I'm moving along at a snail's pace with this build as I'm packaging using pacman, basically starting from scratch as my old LFS PKGBUILDs are hopelessly out of date (and for a completely different build type anyway), but I expect that not much will change. It'd basically need to loose any mv bin/blah -> /usr/bin, same with /lib and vice versa, and any dual-homed symlinks in /lib and /bin dirs if any still exist). If any interest, I'll document changes as I go. I plan to work from the book sources anyway, borrowing a few minor bits from Arch, but won't be all that different from lfs-systemd when done (short of the above change). Instructions should remain mostly the same for both books (pretty much as they are now), we don't care about /usr vs / (only matters if packaging, in which case, simply create the symlinks in DESTDIR before install). > > --DJ > > Hi DJ,
After reading the page that you sent out in this email, I am truly considering revisiting it. I didn't even know that the proposal existed. When I run through my next build, I will take a look into the effort required to implement this. This will simplify packaging for people that do it, but it will also simplify porting of programs. I like it! I have quite a few proprietary Unix applications (old versions of PVS Version Manager and a few others) that require a ton of work to set up a new machine from its HP-UX roots to Linux. My hope is that something like this would simplify the process. That said, I will experiment with it, but I have no guarantee of when I can say anything about it. I will be more than happy to hear your results as well. I wish I had more man-hours to dedicate to LFS, but I am so busy right now that it is hard. Douglas R. Reno --(B)LFS systemd maintainer
-- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
