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
Reply to: