Re: next steps after usrunmess
On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote:
> > - reverting the changes in deboostrap in sid, bullseye (and ideally
> > in buster too),
> > - reverting the notion that split-/usr is unsupported (which includes
> > the extremely confusing interpretation about this applying to
> > sid/testing too), and update documentation such as release-notes,
>
> This bullet point response confuses me - and then what?
>
> If I understand your position correctly, you don't want merged-/usr as
> an end-goal and you disagree with usrmerge transition as a hack. In
> order to achieve the result above without bypassing Debian processes,
> the formal method would to pass a GR overriding the tech-ctte minority.
> Is the only reason you haven't proposed that as a GR that you've already
> sunk too much energy into this? Or that you don't trust that process?
My question is the reverse. If there is rough consensus that we as a
community *do* want to go forward with /usr unification in a way which
is compatible with all of the other distrubtions --- and Debian is
definitely in thet trailing edge here --- and a very small number of
dpkg developers are refusing to help resolve these issues, are they
entitled to perform a pocket veto on /usr unification?
Simon and I have proposed technical paths forward which appear to be
sound, and I note that Guillem has not commented on them. Which is
why I haven't really participated in this thread in the last couple of
days; I've said my piece, and if folks who essentially want to
rollback the clock by several years refuse to engage, just simply
repeating my points doesn't seem to be a good use of electrons.
But the question remains --- how do we as a community move forward?
Debian is made up of volunteers, so we can't *force* the dpkg
developers to do anything they don't want to do. So what then?
Does someone need to create patches to dpkg which attempt to teach it
that /bin/foo and /usr/bin/foo are the same file, if there exists a
symlink from /bin to usr/bin? And then with some kind of process,
maybe with the blessing of the technical committee, upload it as an
NMU over the objections of the dpkg developers if they continue to
refuse to engage with solutions that proceed forward with
/usr-unification? That seems to be rather non-ideal from a community
perspective. But what's the alternative? Should a single DD have the
power to overturn a techical committee because they are the maintainer
of a highly important package? That doesn't seem great, either.
As I've said before, I've never been a fan of /usr-unification; I
don't hate it, but I've never thought it was worth it in and of
itself, other the "compatibility with the rest of the world argument".
I'm not a huge fan of systemd, either, although I never hated it as
much as some. But the entire Linux ecosystem has spoken, and so my
personal views aren't really important at this point. Part of living
in a community is realizing that one doesn't always get one's own way,
and subsuming one's individual wants for the greater good.
So I repeat the question to the entire community --- what is to be
done? How do we move forward?
- Ted
Reply to: