[gentoo-amd64] Re: Systemd migration: opinion and questions

[Duncan]

Marc Joliet posted on Sat, 23 May 2015 10:49:07 +0200 as excerpted:

> Am Thu, 21 May 2015 09:36:28 +0000 (UTC)
> schrieb Duncan <1i5t5.duncan@×××.net>:
>
> [...]
>> I decided to keep systemd, and ultimately, to unmerge openrc
> [...]
>
> I forgot to ask about this: how did you go about doing that?  I'm still
> waiting for the following two bugs to be resolved:
>
> https://bugs.gentoo.org/show_bug.cgi?id=504116
> https://bugs.gentoo.org/show_bug.cgi?id=511500
>
> Do you have none of the affected packages installed, or...?

Good question!

Answer: "or..."  Very definitely "or...", as you will see below. =:^)

functions.sh is easy enough to fix, if you're willing to create a single 
symlink, manually.

$ equery belongs functions.sh
sys-apps/gentoo-functions-0.10 (/lib/gentoo/functions.sh)

The package gentoo-functions is /supposed/ to replace a couple gentoo-
specific files formerly found in openrc, thereby making openrc optional 
for those using other init systems (like systemd).  One of those files is 
functions.sh[1].

But the old /etc/init.d/functions.sh location was hardcoded into a lot of 
gentoo utilities over the years, some of which don't get updated very 
often especially for stable, and the new /lib/gentoo/functions.sh 
location, while more appropriate, still can't be found by some of these 
apps.  That's what the first bug is about.

Simple enough fix -- ensure the gentoo-functions package is installed (it 
should be as it's a dependency of enough stuff, including current glibc 
packages!), and do a manual symlink from the old location to the new 
one.  Viola! No openrc needed for THAT any more, and because the new 
location's file is still packaged, any updates to it should occur 
normally and will be simply picked up by anything still using the old 
location, since it's a symlink! =:^)


The other bug deals with the base-profile placing openrc in @system, 
since until the functions.sh bug is finally resolved, it really is a 
system dependency of a sort as it provides the old-location functions.sh, 
even if you're using something else as init system.

First let me caution that the below specific action is rather "out there" 
and cannot be expected to be supported by gentoo, tho that said, it 
hasn't caused /me/ any issues, running it for I'd guess a couple years 
now... and for sufficiently experienced gentooers it's not really as 
unreasonable as it might sound...

Warning out of the way...

What I've done here, actually quite some time before I switched to 
systemd, is negate my entire @system, so it's entirely empty.  I actually 
get a pretty dire looking warning about the empty @system when I run 
emerge --depclean, but when I negated @system, I did so one package at a 
time, and added packages to my @world list as necessary, where I really 
did need (or want) them and nothing else depended on them.

Of course this only works for gentooers with enough experience to tell 
what @system packages that would be removed when it's empty, are really 
needed after all.  I obviously had the required experience as I've been 
running @system-less for quite some time now, but it's obviously not for 
everyone.

Obviously for things like virtual/editor, I already had my editor of 
choice in @world, and thus could simply negate the virtual entirely.  In 
other cases, something else in @world has a dep on the @system package, 
so I didn't need to put that package in @world when I took it out of 
@system, at all.

And things like busybox... aren't really necessary at all.  In fact, I've 
actually never had it installed in the over a decade I've been on gentoo, 
as for whatever reason it wouldn't build when I originally installed, so 
I temporarily bypassed it as I knew it was an emergency thing, and that 
temporary thing just got longer and longer, until I decided I didn't need 
it at all.

Instead of something like busybox, I keep (at least) two root partitions 
available, my working copy and my backup.  The two partitions are the 
same size, and contain pretty much everything installed by portage (with 
a small exception for some state files in /var, since I keep root mounted 
read-only by default and they need to be writable).  Periodically, when 
the system seems to be stable, I'll blow away the backup root with a 
fresh mkfs, and then copy everything back onto it, creating a new backup 
that's a copy of the same working system setup that I'm using at that 
moment.  Of course a good sysadmin never considers a backup done until 
it's tested, so then I test-boot to it to ensure it works.

Meanwhile, in grub2, I have a menu entry that sets a variable used in the 
root= entry on the kernel commandline.  By default, that var points at 
the working root, but if I invoke that menu entry, it changes the var to 
point at the backup root instead, thus letting me boot either working or 
backup root, by just selecting an entry in the grub2 menu before I load 
the kernel, if I want to boot the backup.

So I don't need something like busybox, because in the event I screw up 
the working root and can't boot it, I can boot the backup, which is a 
copy of the very same working config I was using when I took it.  So 
while it might be a bit old if I haven't updated the backup in awhile, 
it's tested to boot properly, when I made the backup.

And actually, my working system and primary backup are on dual SSDs in 
btrfs raid1 mode, with a partition each for the working and primary 
backup, and I have another backup on my old spinning rust drive as well, 
on reiserfs in case btrfs bugs out on me and the working and primary 
backup are thus unusable, with yet another grub menu entry to set it up 
for boot.  Meanwhile, I have a separate grub installation and separate 
/boot, on all three drives, so as long as all three drives don't go out 
at once...

And of course ssh, still part of @system altho people running local 
systems really don't need it as part of @system, works just fine in 
@world, if you actually do want/need it.

Just some examples...

OK, but how does this @system negation actually /work/?

Simple enough.  The portage (5) manpage has the documentation, but 
briefly, profiles dirs can have packages files.  In these files are 
entries like this:

*sys-apps/busybox
*>=sys-apps/baselayout-2

The * indicates that this package should be added to the @system set.  
(In new enough portage and profiles there's also @profile set entries, 
see the manpage, but they haven't bothered me yet, here.)

And critically, in cascading profiles, which pretty much all profiles are 
these days, -* indicates a *REMOVAL* from the @system set.

Two additional missing pieces:

/etc/portage/profile/packages... is where you put your installation-
specific things, and where I put my negations.

Note the versioned baselayout-2 entry above.  These versioned entries 
must be negated with the identical version, or they don't end up 
negated.  So that baselayout entry would be negated like this:

-*>=sys-apps/baselayout-2


As I said, with a clean emerge --depclean --pretend, I negated one or a 
small handful at a time, then did an emerge --depclean --pretend and 
noted what the new @system removals had now cleared for removal as 
nothing else depended on them.  Some, such as virtual/editor, I already 
had an appropriate editor in @world for and thus removal of the virtual 
was fine.  Others, such as sys-apps/busybox, I never had installed in the 
first place.  Others, including sys-apps/man-pages, I added to @world, 
and still others, including sys-fs/e2fsprogs, were deps of something else 
and thus didn't need a specific @world entry to keep depclean from 
removing them.

And of course, the two that triggered the subthread, openrc and 
baselayout.  Openrc I originally kept in @world as I was using it for init 
when I did the @system negation.  Since it was then in @world, not in 
@system, when I switched to systemd for init, it was easy enough to 
unmerge it, just as I would anything else in @world.

Meanwhile, systemd itself depends on baselayout, and I'd guess openrc 
does as well altho I don't remember for sure and am lazy to look ATM, so 
it stays on the system even tho it's not in @system any longer.


Finally, one additional thing to note about @system, that's different 
when you don't have it.  If you try to unmerge a package in @system, you 
get a dire warning.  Obviously, if your @system is empty and the same 
package is simply listed in @world or a dep of something in @world, you 
won't get that same kind of dire warning trying to unmerge it.  For 
experienced gentooers that should be no big deal, as they wouldn't think 
of trying to unmerge really critical stuff like glibc anyway.  But for 
less experienced gentooers, those dire warnings might save their *** once 
in awhile, making them useful to have.  If you're at all unsure whether 
you need such "safety railings", emptying @system entirely probably isn't 
something you should be considering.


But, just because you aren't emptying @system entirely, doesn't mean you 
can't negate specific @system package entries, if you're sure you don't 
need them.  For systemd users who don't want/need the fallback to openrc 
in case systemd fails to boot, or where the openrc config is getting 
dangerously outdated due to lack of use such that even if systemd breaks, 
they'd be afraid to simply set init to run openrc instead, lest it break 
their system further with an unconfigured and untested boot, and who have 
or will take care of that /etc/init.d/functions.sh file via manual 
symlink, openrc may well be one such entry to consider negating.


....

So you see why I said "or..." DEFINITELY "or...", above! =:^)

---
[1] gentoo-functions file replacements:  In addition to functions.sh, the 
other is consoletype, executable and manpage, see the results of equery 
files gentoo-functions.

-- 
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