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 way. 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