Web lists-archives.com

usrmerge -- plan B?




Hi!
There's been another large bout of usrmerge issues recently, and a bunch of
new problems have been identified.  The point of the whole idea has been
questioned, as well.

Thus, I'd propose holding our horses and thinking a bit.  I'd also like to
suggest an alternate approach:

* let's scrap the usrmerge package
* move binaries to /usr/bin one by one, without hurry.  If it takes 10
  years, so what?
* /bin would be left populated with nothing but /bin/sh, /bin/bash and
  whatever else POSIX demands.


Note that usrmerge isn't really related to dropping support for split fs
without initrd.  That's already done, and was a case of trading a sizeable
drop of developer effort for the loss of a rare user setup.  I for one
consider it an okay deal -- some disagree, but it's a separate matter.
Somehow, most of usrmerge flamewars are about that topic.

What we are discussing here is the plan to 1. move everything from /bin to
/usr/bin[1] and 2. "ln -s /usr/bin /bin".

That move turned out to be problematic (see #914204, and individual FTBFS/
uninstallability/unupgradeability bugs).  Even the proposed workaround, to
disable usrmerge on buildds, doesn't really work -- a lot of binary uploads
are still built on developers' machines, and remember that there's a whole
world besides DDs -- being able to compile packages is a core freedom for
many of our users, and they usually lack the knowledge how to troubleshoot
this particular problem.

Another question is, why?

14:18 < bunk> What are the "of course" benefits of merged /usr for a user? 
              For a distribution I see the benefits of moving to merged /usr
              only, but I honestly don't know in what cases "Installing the
              usrmerge package will solve your problem." would be a correct
              answer to a user problem.

... which hasn't received an answer.

The only writeup pro the move I've seen pointed at is:
  https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
which describes other users, but provides no compelling arguments.  Its
main reason is compatibility with Solaris -- which hasn't been relevant for
a long long time.  Even the other distribution (Fedora) that has done the
split is rapidly following Solaris into obscurity (the whole RPM world has
gone to 20% of web servers from 65% a few years ago, other server uses seem
to be alike[2], Red Hat has been gobbled up).  This leaves mostly claim #4:

# Fact: The /usr merge makes sharing the vendor-supplied OS resources
# between a host and networked clients as well as a host and local
# light-weight containers easier and atomic.  Snapshotting the OS becomes a
# viable option.  The /usr merge also allows making the entire
# vendor-supplied OS resources read-only for increased security and
# robustness.

-- which is untrue as a system with /etc and /var out of sync with /usr is
broken.  There are attempts of reducing /etc but I have seen nothing about
/var.

Thus, it seems to me that the plan A for usrmerge has serious downsides for
dubious benefits.  What about the plan B I described above?


Meow!

[1]. For simplicity I'm not mentioning /sbin.
[2]. It's hard to find good data on anything but web servers.
-- 
⢀⣴⠾⠻⢶⣦⠀ .globl _start↵.data↵rc: .ascii "/etc/init.d/rcS\0"↵.text↵_start
⣾⠁⢰⠒⠀⣿⡁ mov $57,%rax↵syscall↵cmp $0,%rax↵jne child↵parent:↵mov $61,%rax
⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall↵jmp parent↵child:
⠈⠳⣄⠀⠀⠀⠀ mov $59,%rax↵mov $rc,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall