[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#994388: dpkg currently warning about merged-usr systems

On Fri, 2022-04-08 at 15:56 +0200, Ansgar wrote:
> On Fri, 2022-04-08 at 14:31 +0100, Wookey wrote:
> > At this point I am more disappointed in the people who keep insisting
> > that 'it mostly works' is good enough, than I am in the bloody-minded
> > dpkg-maintainer. Debian is not a 'mostly works' project. We do things
> > properly - or at least we used to, even if that takes a long time.
> > 
> > Some people have cited the multiarch dpkg changes as an example of
> > work on dpkg being difficult. I was quite closely involved in all
> > that and yes it took a long time but it was done right in the end,
> > and it was the dpkg maintainer who insited on it being done right.
> No, multiarch is in the "mostly works" state.
> If you wanted to do things "properly" (whatever that means), we would
> still not have multiarch (given the bugs are not fixed).
> Ansgar

I find it quite interesting that just the other day, another developer
who is vehemently opposed to merged-usr used multiarch as an example of
a rushed through change that is broken - it was on IRC in public, so I
quote: "He objected to merging multiarch before it was fully done, and
now we're stuck with a broken design that can't handle arch:all
packages well". So depending on who you ask, multiarch goes from being
an example of "we do things properly and it's done right" to "it's
broken", but is always invariably proof that usrmerge is bad either

Considering on Bullseye you can do 'apt install bash:arm64' and hose
your machine by typing "Yes do as I say", it would appear to me the
situation is quite a bit worse than what we and Ubuntu have now with
merged-usr, where the actual worst thing that happens is that sometimes
you have to type 'dpkg -S' twice, once with a prefix and once without.
Yet, I don't think multiarch should be reverted, or it's bad per se.

Also the insistence on "you haven't provided patches" is interesting,
given that first of all a patch was provided some time ago and as far
as we've been told was summarily dismissed as "usrmerge bad", and
secondly there's examples that providing patches doesn't help that much
with this package, if the maintainer doesn't like the change in
principle. See for example zstd support, which is the next ticking bomb
waiting to go off - Ubuntu switched to zstd for all its packages, so
all Ubuntu-built packages are unreadable on Debian right now and for
the foreseeable future - and there's TONS of third-party repositories
with very popular software out there, distributed a single .deb for all
deb-based distros (yes it's bad, but that's how it works), that get
built on Ubuntu. They will likely stop being installable on Debian at
some point, probably as soon as those external build systems get
updated to Jammy. The Ubuntu developers (and others) meticolously
submitted patches, and keep updating them and re-basing and re-
submitting them to dpkg as recently as this week, but as far as I can
tell from the bug tracker the last time the maintainer meaningfully
engaged with them was 4 years ago in 2018.

To me hiding behind "if only you provided patches" seems like badly
misreading the whole situation. The issue isn't technical, it's social,
it's about project governance, following rules we give ourselves, how
collaboration for one of our core packages works in _reality_ (as
opposed as how we think it does or should work), doing what's best for
our users given the realities in the wider world, and how to deal with
a situation that is by now beyond disfunctional. I understand that it
might hurt to hear that the project one really cares about is in a bad
spot, but hiding these problems behind perceived technical issues is
not going to help resolve them.

Kind regards,
Luca Boccassi

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: