Re: Bug#994388: dpkg currently warning about merged-usr systems
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
Reply to: