Hi Wouter, On Fri, 2022-04-08 at 09:36:21 +0200, Wouter Verhelst wrote: > FWIW, I think the TC should punt this bug to a GR.
I don't think deciding technical matters via GR is a great idea… but I guess it's a good opportunity for some people to put on the table getting rid of the "dpkg maintainer" (not talking about you). :/ > The dpkg maintainer has chosen not to engage with the TC in #994388, I think I've made my position regarding the TC public for a long time. Recentish summaries: <https://lists.debian.org/debian-devel/2016/11/msg00458.html> <https://lists.debian.org/debian-ctte/2018/07/msg00021.html> <https://lists.debian.org/debian-policy/2019/07/msg00092.html> I don't think I've "engaged" with the TC since around 2013. I do of course recognize its authority, even though as stated above I think it's an awful way to resolve issues. > and now seems to be actively subverting a validly-made TC decision. Hmm, this characterization of my supposed motivations and objectives, seems unfair, so I'll try to explain my train of thought below: (Also I'm assuming we are talking about the warning that has since been silenced in Debian, for a week now.) - There's been already a notice/warning in the dpkg's reportbug bugscript for a long time now. - I'm of the opinion that dpkg users (in Debian and elsewhere) deserve to know whether dpkg will be able to operate correctly on *their* system. - The warning was added via dpkg's postinst, which gets emitted only during installation/upgrade, which to me meant, less technical inclined users which might not be able to evaluate it are not going to see it from a GUI or similar, and that even on oldstable to stable upgrades, it would probably be missed due to being drowned on all the other output text. So I honestly do not expect it will have a great impact on such upgrades anyway. - In Debian, most of the breakage in dpkg _might_ be externally detected and prevented by QA tools, as long as the users would not use external repos, backports, or old .debs say from snapshots, or directly interface with dpkg tools, which seemed would apply in most cases to GUI users that would not see the warning at all anyway. - The TC ruling stated that Debian supports for now both layouts, while dpkg does not and has never supported the merged-usr-via-aliased-dirs one, and given that Debian is not supposed to leave people behind or require them to reinstall in case they are not yet using merged-usr-via-aliased-dirs, it seemed fair to me to let people decide about these potential current trade-offs by themselves (and definitely not to use them as a mob to pressure or attack anyone with!). - I've mentioned this in the past already, and even if I now suddenly found the motivation with the previous and current climate, to add proper support for this into dpkg, only adding the foundation and being able to use it might take from one to two Debian release cycles anyway: <https://lists.debian.org/debian-devel/2021/08/msg00363.html> <https://lists.debian.org/debian-devel/2021/08/msg00103.html> and that does not include actual proper support for the thing. - You talk about (ab)using power, but I _think_ I'm pretty careful and mindful about the responsibility that comes with being upstream and maintaining packages. In the end I think this could be mischaracterized about any upstream or maintainer, TBH :/. If I had wanted to "abuse power" (something that has never even crossed my mind doing as such, as I think it would have been completely inappropriate), I could have say Conflicted on usrmerge (which while I've always thought it was producing fsys layouts unsupported by dpkg, the users should be obviously free to do with their system as they please), or say even try to run dpkg-fsys-usrunmess (which on the same note, is something that I cannot decide on behalf of the users). - If I had known that people in Debian would get this offended about a factual warning to the point of picking up the pitch forks, with the subsequent actions which I perceive as bullying with calls for expulsions, DM demotions, upload privs removals, etc, etc. I'd probably have still added the warning but directly silenced for Debian, because life's too short, yes. - The warning did not intend to claim that Debian did or did not support anything. I thought it was obvious this being a dpkg warning, it implied it was stating what dpkg supports or not. Also didn't want to drown the screen with text, so initially went for a fairly short note. This seemed to confuse people, so I updated it to try to make it clearer, and expanded it a bit. Before silencing it on Debian, as per the above. - dpkg is used way beyond Debian, and its own maintscripts are shared by any distribution making use of them. I've actually been pondering for a long while to make the dpkg tool suite non-native, to perhaps make this all more clear. So, given the above, my intention was not to try to subvert or work against that TC decision. But reading now your statement and someone else mentioning the Debian Constitution $2.1.1, I guess I can see how some people could perceive it like that, and I'm truly sorry about that. :/ The reactions have been shoot first, ask later (if at all), which also seemed dismaying to me, of course communication around merged-/usr have not been working in Debian at all for years now… :(, Guillem
