Re: support for merged /usr in Debian
]] Ian Jackson
> This thread contains a fair few assertions that certain configurations
> are `broken' or `unsupported'; but these assertions sit alongside
> reports from actual users that these configurations do work for them,
> and expressions of the wish that they should continue to do so.
A lot of this thread reminds me somewhat of the various people being
very upset when gcc changes behaviour on something which is either
undefined in the C standard or implementation defined. The other thing
it reminds me of is https://xkcd.com/1172/ . Nearly any change we make
has a risk of breaking something for somebody out there if our users
have explored the enterity of what you can do with Debian and that has
some reasonable chance of success.
To counter this, we (collectively), need to do a couple of things:
- Be reasonably clear about what you can expect will continue working
and what configurations we actively care about even if they're not
what we do by default. We care about, say, being able to run a
self-compiled kernel, even if we don't require people to build their
own kernel. However, we also require people to run a reasonably
recent kernel, or thing won't work. Glibc has version requirements,
apache uses epoll (something where we did have to wait a release to
use it, because we wanted to support running a partially upgraded
system). It's a two way street and both we as a project and our users
need to be reasonable.[*]
- When we change the expectations and the operating envelope, we need to
communicate that. We also need to (whenever at all possible) provide
a migration path. In some cases, we might be able to say «you can run
with your old setup, but then you have to do those five steps for it
to continue working». The 300loc initramfs elsethread is an example of
this: You can have (almost) no initramfs and then you can continue
with your /usr and / on separate partitions. Again, people need to be
reasonable and constructive. Labelling initramfs as «evil» is not.
What we can't do is to stop making changes because it might break
configurations, especially configurations we don't know about. That's
how this has «always» worked. We make changes, if it breaks something
people use, you get bug reports and work it out from there.
[*] «Reasonable» is hard to define, which is part of the reason we end
up with those arguments. I don't have a good test for reasonableness
outside of human judgement.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Reply to: