Re: merged /usr
On Tue, 2021-07-27 at 11:44:32 +0200, Wouter Verhelst wrote:
> On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote:
> > On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> > > I've suggested previously that we can easily make it RC for bookworm to
> > > have a file outside a limited set of directories (/etc and /usr would be
> > > OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
> > > This is easy to detect with a lintian check and reasonably easy to
> > > implement
> >
> > I don't think that works in general without breaking some of Debian's
> > axioms around Essential packages, as previously described here:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118
>
> Yes. Those arguments didn't convince me then, and they don't convince me
> now.
Ack, these are very contrived.
> A package in the essential set could work around the issue by moving a
> file around and creating a necessary symlink in preinst rather than
> shipping things. The set of Essential packages is small however, and
> most packages can ship a compat symlink.
Yes, along those lines. To try to do something resembling dpkg's safe
behavior, we'd need to do in preinst, something like:
- if /usr/foo does not exist:
- copy /foo to /usr/foo
- replace /foo with a symlink to /usr/foo
Then dpkg would replace /usr/foo with the new version. Of course this
is all kinds of suboptimal, as the .debs will still not ship the actual
symlinks and it's trying to replicate what dpkg is designed and supposed
to do to handle Essential packages safely, even when doing this kind of
switch, where it will delay symlink installation as the last step… but
we cannot do that right now due to the incorrect restrictions imposed by
merged-/usr-via-aliased-dirs. :(
I have very deep and strong regrets about having removed compat symlinks
under /, to make it possible for people that wanted to locally use
the usrmerge hack. I guess the lesson learned with this episode, is
that in the future, similar stuff cannot be let through, when people
promise this will not be pushed into the distro, and it's just for
local deployments and similar, or we end up with this kind of mess. :/
> > I have a longer mail written with possible ways forward, which I'm
> > deliberately not sending right now, because the first step in all of these
> > plans is "release Debian 11" and I don't want to distract the people who
> > are making that happen (any more than has already happened).
>
> This is so exhausting.
Indeed, very. The impression I'm getting is that instead of stopping the
bleeding effect, this is being let fester to the point any option will
be terrible, so anything, regardless of its badness will seem acceptable
to make progress at that point.
> Yes, I know the release is close, and yes, I know that some people are
> immensely busy working on that. I want to help them do so in any way I
> can, but they're not *required* to read -devel, and "they might read
> this and get distracted" seems like a pretty poor argument.
>
> I'm not busy with the release. Are you? If not, you *can* actually come
> up with an argument right now, and I promise not to insist on any
> decision being made until the release happens, so that those
> hypothetical people who *are* busy with the release can still chip in
> later if they choose to do so.
Yes, I'd say this is one of Debian's development fallacies. You know
you are dealing with strong arguments when this comes up. Also the
proponents are not worried now that this is being shoved down by
force due to the involvement of the TC…
Thanks,
Guillem
Reply to: