Re: support for merged /usr in Debian
On Mon, 4 Jan 2016 14:15:21 +0100, Christian Seiler
<christian@iwakd.de> wrote:
>On 01/04/2016 11:44 AM, Marc Haber wrote:
>> On Sun, 3 Jan 2016 21:35:39 +0100, Christian Seiler
>> <christian@iwakd.de> wrote:
>>> So that was the state in February of 2011, when the warning was added
>>> to systemd and the systemd developers recommended the use of the
>>> initrd: mounting /usr from a running system is broken. Either it is
>>> already completely broken in some cases - and for all other cases where
>>> it currently works it is broken maintenance-wise.
>>
>> Declaring something that was the normal use case five years ago as
>> broken is a blatant sign of disrespect for users.
>
>Ok, so when Wheezy came around, 5 years before that a normal use case
>for init scripts was to have a fixed start/stop priority that was used
>when calling update-rc.d - and in Wheezy (this was pre-systemd!) the
>update-rc.d implementation completely ignores the start/stop priorities
>and says it only does dependency-based boot now (it shows a warning if
>priorities are still specified). Is that also a blatant sign of
>disrespect for users?
No, this change was largely painless. I had only systems with badly
maintained third-party packages break.
>With your argumentation you could argue that ANY
>change is a blatant disrespect for users.
No, this is only the case for really intrusive changes that noone had
asked for.
>I'm really curious: what's your solution?
Keep support for things that used to work for, say, at least three or
four stable releases, document that and commit to it. And, of course,
stick to it.
That way, a local admin can change installation to adapt to new ways
and to necessary migrations of existing systems on _her_ schedule.
Forcing intrusive and time-consuming changes with a single stable
release is bad bad bad.
>Diagnosis: mounting /usr from / doesn't work properly
It works fine for the vast majority of setups, including LVM and
crypted file systems. It breaks for important corner cases such as
having /usr on storage media that needs exotic drivers or the network.
I'd hardly call that "broken".
>Now what do do about it? You seem to be suggesting that people should
>try to maintain the current state of affairs regardless. There's ample
>evidence that that simply won't work.
I don't see this evidence as compelling as you do.
>Suggestion by other people: ok, so we still want to support a separate
>/usr partition, so what do we do now? Oh yes, we just mount it already
>in the initrd, because that already has support for mounting
>filesystems (such as the root filesystem). Now people can still have
>their separate partitions but we don't have to support the use case of
>mounting /usr from / anymore.
That's not nice, but fine and acceptable _IF_ there is commitment to
keep things this way. There are significant changes to the initrd on
the horizon, and those changes involve switching to a software with an
upstream that has a reputation about not giving a damn about existing
systems because they have been broken and maintained the wrong way all
time before and declaring having no hooks as design feature.
>Plus: if we do that, we get a exciting possibilities, because we can
>just put everything in /usr, which is what the UsrMerge is all about,
>so we can actually make lemonade from those lemons.
What about if I prefer something that tastes like oranges? Do I have
to change to lemonade when the release team pushes the button? An
Universal Operating System should not declare oranges as "obsolete"
just because lemons do have more vitamin C.
>Response: well, in some cases a full-blown initrd is not an option. I
>respond in this thread with providing a 300 LoC PoC for a minimalistic
>initrd that's *reall* small. I ask people who have been complaining
>here whether this would address their concerns. What do I get? Silence.
I appreciate that effort, but for me it misses the point. I have
always been using initramfs, initramfs-tools do a splendid job, and as
long as this functionality is preserved and Debian commits to this I
am just fine with a /usr merge stretched about a few releases. This is
nothing we have to force for stretch or buster.
>So really, what would you suggest? How would you solve this issue?
Documentation and commitment.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Reply to: