On 01/08/2016 10:21 AM, Marc Haber wrote:
> On Mon, 4 Jan 2016 13:38:15 +0100, Christian Seiler
> <christ...@iwakd.de> wrote:
>> On 01/04/2016 11:41 AM, Marc Haber wrote:
>>> We have already shown how "much" we care about the users of non-Linux
>>> kernels in Debian ("not at all, they can happily go fishing").
>>
>> So why aren't you on the list of porters for either Hurd of kFreeBSD?
>
> Since when does one have to actually work on something to be allowed
> to find it important and interesting.
I'm apologize, I was being a bit too snarky here. I just had a lot of
experience with many people that don't care about non-Linux ports at
all (as evidenced by their other actions) but said things very similar
to what you said in order to complain louder. While that may not be
accurate in your case (again: sorry), I am a bit frustrated with that
type of comment when it comes from people who don't actually work on
those ports.
>> Sorry, but this is bogus, because this is a problem you have on every
>> every upgrade. In the past I've already had to repartition systems
>> because / had become too small, because the amount of software required
>> to be there had grown (to support more storage solutions for mounting
>> /usr) and also the kernel modules had grown.
>
> 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...
> In fact, as I have
> understood things, software will move from / to /usr,
Exactly, this is what is proposed.
> 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...
Note that on a typical system writes to / are more likely than writes
to /usr (usually only APT/dpkg writes to /usr), so one could argue
that /usr is typically a bit safer from corruption because it
experiences less writes than /.
=> In that scenario, with /usr being OK but / being corrupted,
UsrMerge would improve changes of having a bootable system.
(You don't necessarily need an intact /etc/fstab here, btw.,
since there are standards for how to auto-detect the /usr
partition according to the GPT partition type, if you use
that. Don't know what Debian's current support of that is,
but the idea exists in principle.)
Failure cases happen. Different file system layouts will have different
consequences for these - but there always will be some things better
and other things worse depending on what kind of failure you have with
which kind of configuration. So I don't think it's as clear-cut as you
may think it is when it comes to recovery.
>> [Repartitioning due to updates]
>
> Yes, this happens. Do we really have to _force_ this? It is annoying
> enough when it happens caused by the normal flow of things. Even if
> this is the case, not all systems will explode during the same system
> upgrades, allowing the local admin to spread those changes over two or
> even three releases. If we would, in some future, ship an upgrade that
> uncaringly would _require_ a repartitioning, this spread would not be
> possible, and it would undoubtedly call up management attention, which
> could in turn lead to management taking vendor decisions that we don't
> want.
Well, but that can go both ways:
1. /usr is too small, then UsrMerge will require repartitioning
2. / is too small to handle the additional binaries that were added
to / during the next release, then UsrMerge would prevent
repartitioning, which you'd have to do without it
So also here it's not clear to me whether it will require more or
less repartitioning. Could go either way.
>>> And, I really don't want to have to adapt, test and verify scripts and
>>> backup schemes to changed partition layout. This will be necessary for
>>> new systems, and it is really a horror vision to have to do this for
>>> existing systems during upgrades.
>>
>> You will always have to adapt things to upgrades, because lots of small
>> details can change.
>
> That does not mean that we're entitled to needlessly add a big detail
> that changes.
In some sense it's a big change, in some sense it's not. For most
software, it will be absolutely trivial, because the programs will
all still be available.
> [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.
> 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.
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.
Look at it this way: Debian has a LOT of software packaged for it.
Any large infrastructure change, be it systemd, be it UsrMerge, be it
something else, will require that there is a significant level of
compatibility there - otherwise a ton of other packages would run into
problems.
From an end-user perspective, these large infrastructure changes were
always the least of my worries when upgrading, what always cost me the
most time was the configuration changes I had to make because of new
versions of the software I was running. By far.
So if I were to find myself in a similar situation, UsrMerge would
probably be one of the least scary things related to a dist-upgrade.
(Assuming disk space is sufficient.)
>> 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?
>> So we can either keep everything as is, with no plan for the future,
>> and things will simply continue to deteriorate - or we embrace the fact
>> that what has been done in the past doesn't work anymore, and see how
>> we can improve the situation from there.
>
> 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.
Two predictions, based on how Debian has worked in the past:
1. I don't think that anybody is going to _actively_ break mounting
/usr from / before Stretch is released, but things will probably
deteriorate because of new library dependencies that would have to be
moved from /usr to / and aren't and other problems related to PAM, udev
rules, etc.
2. The UsrMerge proposed here is optional and will remain so for
Stretch.
Suggestion (irrespective or UsrMerge):
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,
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.
Regards,
Christian
[1] https://github.com/chris-se/tiny-initramfs
(Now with UUID= support for ext4/btrfs/xfs.)
Will package for Debian soon.
signature.asc
Description: OpenPGP digital signature
