Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
Hi Ansgar,
I'm speaking with a CTTE hat here, but not representing CTTE consensus.
On Wed, May 10, 2023 at 11:47:42PM +0200, Ansgar wrote:
> Dear ctte, please consider overruling the dpkg maintainer to include
> the patch from #994388[1].
I think we need to reject this request on multiple levels.
On a social level, I see that you are frustrated with how dpkg is being
maintained and how communication does not work out in practice. While
part of that can be attributed to the dpkg maintainer, this goes both
ways and the way you refer this matter to the CTTE without even
attempting to resolve it by other means just serves to deepen that
dispute. I see that the dpkg maintainer has recently contributed
constructively to the discussion about how dpkg can be part of a
solution for the problems resulting from the /usr merge. I have a hard
time saying the same about your interaction here. Therefore, I think
your request should be rejected as not being serious.
On a process level, I think I miss attempts to resolve this with the
dpkg maintainer in a constructive way. The present discussion clearly
shows that dpkg's support for how Debian deals with merged /usr is
lacking. We are dealing with multiple file-loss scenarios (something we
otherwise consider grave) and issuing a warning about such behaviour
seems fine to me. On the other hand, much of the project seems to agree
that the way this warning is worded is far from optimal and evidently
leads to confused users. And while it may seem that any attempt at
resolving may lead nowhere, the same can be said about our dpkg
maintainer's concerns about our /usr-merge strategy and him pointing out
real problems affecting Debian installations in practice. Given the
recent constructive communication, I think it is far from clear that
this option is exhausted. In particular, acknowledging the problems
presented and proposing strategies for dealing with them could go a long
way towards a cooperative solution. At present, I see the options to
keep and to delete the warning on the table, but there clearly is
unexplored middle ground. As such, I think your request should be
rejected as not having exhausted the solution space.
On a technical level, Debian's support for merged /usr is currently
founded on the moratorium preventing breakage. Please observe that this
moratorium applies to Debian and Debian only. We have implemented
processes to validate this. If a derivative wants to use merged /usr
(which probably every derivative should), it certainly needs to prevent
breakage in some way - presumably using a similar process. I think that
the cost of patching dpkg is minor compared to the cost of a process
that prevents breakage arising from our merged /usr strategy. Given
this, a warning-by-default (worded in a better way) for derivatives
actually can be a good thing, because it makes derivatives aware that
they cannot just ignore merged /usr, but have to act. As such, I think
your request should be rejected since the measure is technically
reasonable in principle.
Does anyone mind just closing the bug?
At the same time, I recommend changing the warning. The amount of
feedback we get regarding the warning should make it clear that the
current wording is still seen as offensive and causes confusion. Keeping
the warning in its current form also serves little but deepening the
dispute.
For instance, the wording "going behind dpkg's back" may be considered
technically correct, but it also can be objectively described as passive
aggressive. Just deleting this aspect and instead saying "This system
uses merged-usr-via-aliased-dirs which violates core assumptions of
dpkg." would probably keep the intended message in a less
confrontational way. Elaborating that file loss is being mitigated by a
process (moratorium) on Debian would also help. Looking into the wiki, a
recommendation of dpkg-fsys-usrunmess should caution that using it now
breaks other tool's assumptions such as systemd and is generally not
being tested with QA anymore.
Even if one were thinking that the warning were appropriate as is,
adapting it again due to community feedback would demonstrate empathy
and be a step towards a cooperative solution.
I think our priority should be finding a way to terminate the
moratorium.
Helmut
Reply to: