[gentoo-dev] Re: newsitem: baselayout 2.5 changes
William Hubbs posted on Sat, 10 Feb 2018 12:15:43 -0600 as excerpted: >> # shouldn't appear on a desktop/workstation system, but bugs... >> /srv -> tmp > > Keep in mind that /tmp is wiped during a reboot, so /srv should be > separate from /tmp. FWIW that was deliberate. Indeed, /tmp is tmpfs here. =:^) TL;DR: Stop. The package in question (some indexer kde4 used for its handbooks, IIRC, I'm not even sure it's still needed for frameworks-5 based handbooks or whether it's still installed) is primarily used in web servers and the like, and installed something in /srv to facilitate that. But I didn't need it, was irritated by it, and decided to set things up both to make it temporary, and to create an extremely obvious failure if anything else should ever install anything to /srv that I might actually need more permanently, so with more information if it ever triggered, I could decide on appropriate measures. FWIW, nothing has ever triggered it, so if anything else is or has installed anything to /srv, it's obviously not anything I depend on after a reboot. Of course I could do something similar with a global INSTALL_MASK, but having it pointed at a tmpfs instead lets me examine what's actually installed, if necessary. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: newsitem: baselayout 2.5 changes
William Hubbs posted on Sat, 10 Feb 2018 12:43:08 -0600 as excerpted:
> This is all very custom (Gentoo makes these things as directories when
> the stages are built, so it won't be an issue for a default
> installation).
Of course Gentoo is a rolling distro... no need to periodically reinstall.
While I'm almost certainly an extreme example, people /will/ have a "non-
default" install in one way or another after say a decade-ish of
rolling. After all, if they weren't interested in that sort of "power"
modifications, they'd likely be long gone well before the decade, off to
some "easier" distro as it wouldn't be worth their trouble.
FWIW I've been continuously rolling the same original install forward
thru hardware, software, and needs changes, for nearing a decade and half
now. I'd argue it'd be the rare Gentoo install indeed that remains
"default state" after that sort of time.
Which is why these news items are so critically important. Ideally, they
provide not only a "default install" recipe, but two additional pieces of
critical information as well:
1) What sort of non-default site/install mods are likely to be affected.
(These need not be too specific, just something like, in this case,
"People with symlinks to alternative directory locations or similar site-
specific solutions may need to take particular care here. ...")
2) Preferably some hint at what might be needed.
("... Refreshing your backups before the upgrade and checking site-
specific solutions after the upgrade before reboot, is recommended.")
Because it's a system-critical package this becomes even more important.
(And FWIW, getting a longer heads-up to such changes is a primary reason
I read this list.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: newsitem: baselayout 2.5 changes
On Sat, Feb 10, 2018 at 12:15:43PM -0600, William Hubbs wrote: > On Sat, Feb 10, 2018 at 03:34:51PM +, Duncan wrote: > > William Hubbs posted on Thu, 08 Feb 2018 13:52:56 -0600 as excerpted: > > *snip* > > > > The second change is that baselayout is taking ownership of most of the > > > directories it creates. This includes all directories in / and /usr > > > excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB, > > > baselayout will take ownership of /lib* and /usr/lib* as well. > > > > What's the effect if the "directory" is a symlink to elsewhere? > > When we try to replace the symlink with a directory, the emerge will > fail. It looks like this isn't quite correct, portage doesn't fail to emerge the package, but it doesn't replace the symlink with the directory either. You may be ok, but you'll have to test. This is all very custom (Gentoo makes these things as directories when the stages are built, so it won't be an issue for a default installation). > > Here, the following system "directories" are actually symlinks: > > > > # makes installing grub to multiple devices much easier > > /boot -> /bt > > > > # "reverse" usrmerge > > /usr -> . > > > > # would be /usr/games, but with reverse usrmerge... > > /game -> . > > > > # shorter path > > /home -> h > > > > # lib(64) merge (including /usr/lib(64) > > /lib -> lib64 > > When we get rid of symlink_lib, we will expect both of these (/lib and > /lib64) to be directories. Mgorny can explain more about this, but > linking lib to lib64 is basically a hack. > > > > > > # would be /usr/local, /l is so much shorter > > /local -> l > > > > # (s)bin merge (including /usr/(s)bin) > > /sbin -> bin > > This will be taken care of in the usr merge support. > > > > > # shouldn't appear on a desktop/workstation system, but bugs... > > /srv -> tmp > > Keep in mind that /tmp is wiped during a reboot, so /srv should be > separate from /tmp. > > > > > # shorter log path (/lg as /l already taken by local) > > /var/log -> /lg > > > > > Third is the beginning of support for the /usr merge through the > > > addition of the usrmerge use flag. > > > DO NOT, DO NOT TURN THIS ON UNLESS YOU KNOW WHAT YOU ARE DOING AND CAN > > > HELP WITH TESTING. > > > > What about "reverse" usrmerge as above? Flag on or not? Maybe I just > > turn it on (obviously after updating my backups) to help test? > > The "reverse" usr merge as you call it is a highly custom configuration; > I do not see us building it into baselayout. However, like I said above, > the baselayout changes will not stop you from configuring this using a > combination of /etc/portage/package.env and /etc/portage/env/baselayout. > > William > signature.asc Description: Digital signature
Re: [gentoo-dev] Re: newsitem: baselayout 2.5 changes
On Sat, Feb 10, 2018 at 03:34:51PM +, Duncan wrote: > William Hubbs posted on Thu, 08 Feb 2018 13:52:56 -0600 as excerpted: *snip* > > The second change is that baselayout is taking ownership of most of the > > directories it creates. This includes all directories in / and /usr > > excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB, > > baselayout will take ownership of /lib* and /usr/lib* as well. > > What's the effect if the "directory" is a symlink to elsewhere? When we try to replace the symlink with a directory, the emerge will fail. You will want to take a look at using /etc/portage/package.env and /etc/portage/env/baselayout to set INSTALL_MASK to not install things that collide if you want to keep this setup. https://wiki.gentoo.org/wiki//etc/portage/package.env > Here, the following system "directories" are actually symlinks: > > # makes installing grub to multiple devices much easier > /boot -> /bt > > # "reverse" usrmerge > /usr -> . > > # would be /usr/games, but with reverse usrmerge... > /game -> . > > # shorter path > /home -> h > > # lib(64) merge (including /usr/lib(64) > /lib -> lib64 When we get rid of symlink_lib, we will expect both of these (/lib and /lib64) to be directories. Mgorny can explain more about this, but linking lib to lib64 is basically a hack. > > # would be /usr/local, /l is so much shorter > /local -> l > > # (s)bin merge (including /usr/(s)bin) > /sbin -> bin This will be taken care of in the usr merge support. > > # shouldn't appear on a desktop/workstation system, but bugs... > /srv -> tmp Keep in mind that /tmp is wiped during a reboot, so /srv should be separate from /tmp. > > # shorter log path (/lg as /l already taken by local) > /var/log -> /lg > > > Third is the beginning of support for the /usr merge through the > > addition of the usrmerge use flag. > > DO NOT, DO NOT TURN THIS ON UNLESS YOU KNOW WHAT YOU ARE DOING AND CAN > > HELP WITH TESTING. > > What about "reverse" usrmerge as above? Flag on or not? Maybe I just > turn it on (obviously after updating my backups) to help test? The "reverse" usr merge as you call it is a highly custom configuration; I do not see us building it into baselayout. However, like I said above, the baselayout changes will not stop you from configuring this using a combination of /etc/portage/package.env and /etc/portage/env/baselayout. William signature.asc Description: Digital signature
[gentoo-dev] Re: newsitem: baselayout 2.5 changes
William Hubbs posted on Thu, 08 Feb 2018 13:52:56 -0600 as excerpted: > here is a proposed newsitem for baselayout 2.5. > There are three significant changes in baselayout-2.5. > > The first change is that ROOTPATH is no longer set. This means all of > the *sbin directories will be added to the default path for all users > instead of just the root user. Makes sense and is important for users to know. > I know of no packages outside of > baselayout that used the ROOTPATH variable; however, if packages do use > it, they will need to be adjusted to use PATH instead. Omit that as dev, not user, focused? > The second change is that baselayout is taking ownership of most of the > directories it creates. This includes all directories in / and /usr > excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB, > baselayout will take ownership of /lib* and /usr/lib* as well. What's the effect if the "directory" is a symlink to elsewhere? Here, the following system "directories" are actually symlinks: # makes installing grub to multiple devices much easier /boot -> /bt # "reverse" usrmerge /usr -> . # would be /usr/games, but with reverse usrmerge... /game -> . # shorter path /home -> h # lib(64) merge (including /usr/lib(64) /lib -> lib64 # would be /usr/local, /l is so much shorter /local -> l # (s)bin merge (including /usr/(s)bin) /sbin -> bin # shouldn't appear on a desktop/workstation system, but bugs... /srv -> tmp # shorter log path (/lg as /l already taken by local) /var/log -> /lg > Third is the beginning of support for the /usr merge through the > addition of the usrmerge use flag. > DO NOT, DO NOT TURN THIS ON UNLESS YOU KNOW WHAT YOU ARE DOING AND CAN > HELP WITH TESTING. What about "reverse" usrmerge as above? Flag on or not? Maybe I just turn it on (obviously after updating my backups) to help test? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
