Re: support for merged /usr in Debian
On Fri, 8 Jan 2016 18:37:11 +0100, Christian Seiler
<christian@iwakd.de> wrote:
>On 01/08/2016 10:21 AM, Marc Haber wrote:
>> If hundreds of megabytes of software would get moved from /usr to /,
>> this would certainly overflow my root file systems.
>
>That is not what is going to happen. Nobody ever proposed that. I
>don't know where people constantly get this idea...
We have been bitten by editorial changes in the past. The systemd
debate hasn't made things any easier. And I have over the last years
slowly lost part of my faith that Debian's key people (those that
don't get elected or delegated, but those that have control over key
packages) actually care about the _users_ of The Universal Operating
System.
Yes, I know, servers and buildds run without users, and caring about
users is not always more fun than actually doing development and
building sound, clean solutions.
>> making the
>> system completely unuseable if the multi-gigabytes /usr does not mount
>> for some reason.
>
>The system could also be unusable if / doesn't mount, or the kernel
>image is damaged, or...
Kernel Image and small / are less likely to get damaged than a
multi-gigabyte /usr. At least that's how people think who have known a
40 Meg (sic!) disk as "large". I am pretty well aware that my last
corrupted /usr file system was many years ago, but this is a change
one needs to get used to.
[correct reasoning removed]
>Well, but that can go both ways:
>
>1. /usr is too small, then UsrMerge will require repartitioning
I would probably be possible to have the script doing the merge check
whether /usr is large enough and abort if that is not the case. I
would write a wishlist report, but looking at who's in charge I know
that the answer would be "works for me, send a patch if you want this
change" anyway. And I don't like wasting my time, so I have made a
habit of looking into the maintainer field of debian/control and the
changelog of a package before bothering to write a wishlist report. Or
not write one.
[again, correct reasoning removed]
>> [Potential problems with the backup]
>
>I don't get your remarks:
>
>If you back up every file system with --one-file-system separately,
>(as you appear to be doing) other than the relative sizes of the
>backups (the /usr part is going to be larger, the / part smaller by
>the same amount) nothing at all should change.
One will probably need to adjust the anchor points of the file system
backups.
>> And I need
>> to change documentation, which will probably trigger a review process
>> with management attention.
>
>This may be very unfortunate for you, but I don't think a
>situation like yours should be the basis for deciding distribution
>policy.
Well, Debian is (still) used in big enterprises.
>If you want to "stay below the radar" of management, then you
>probably shouldn't dist-upgrade at all - because a lot more things
>can break on a software-level, where you need to adapt configuration.
>Or some software is discontinued and you have to switch to an
>alternative, where you have to redo your configuration completely.
I have been running Debian servers in production for nearly 20 years,
I can handle upgrades just fine. I just hate it when they are harder
than necessary for reasons that I can't follow.
>>> Sure, you need to test if something breaks (because it always can,
>>> regardless of whether UsrMerge is done or not), but _surely_ you
>>> have a test environment before performing a dist-upgrade of your
>>> entire production system? Right?
>>
>> Not everywhere. This might look unprofessional, but I am usually
>> running the small little gallic Linux village inside "all Windows"
>> shops, and when I ask organizations for test environments, I might end
>> up with "nah, too much hassle, we'll just use Windows instead for your
>> job".
>
>And you can't even spin up a VM with the same size disk etc. to
>test things?
Not for every single machine.
>> You have a big point here. All I want is documentation and commitments
>> so that no surprises come.
>
>If I look at the Jessie release notes (Niels linked them somewhere
>in this thread), they are _very_ detailed, which is probably a big
>reason why the Jessie transition was far less painful as many
>people her have feared. So I don't think documentation will be an
>issue.
I'd prefer to read the commitment in the package itself.
[again, correct reasoning removed]
>2. The UsrMerge proposed here is optional and will remain so for
>Stretch.
... but not for buster
>Come to an agreement within the Debian project that supporting split
>/usr without an initramfs is not going to work out in the long term,
... but split /usr with initramfs is supported and will continue to be
a supported configuration at least in system upgrades.
>document that with an appropriate wording in the Stretch release notes.
>Suggest alternatives to real issues that people face because of this
>change (tiny-initramfs[1] for example). This way, while those people
>using split /usr without initramfs are likely to still be able to boot
>their systems that way with Stretch (so it probably won't break
>immediately at upgrade), they will then be informed that they should
>probably change their configuration
That would be an acceptable outcome.
Greetings
MArc
P.S. I'm going to take a break from frustrating myself, don't expect
me to be back before sunday.
--
-------------------------------------- !! 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: