Re: Bug#994388: dpkg currently warning about merged-usr systems
On Tue, 2022-03-29 at 08:24 +0200, Helmut Grohne wrote:
> That is unfortunate. If I remember correctly, there was some more
> concrete criticism that is still entirely unaddressed in the current
> form.
>
> dpkg is both a Debian package and an upstream project used by
> multiple distributions with different needs. Guillem generally cares
> for the needs of other distributions. As a result, dpkg separates
> policy from mechanism in a lot of places. The patch at hand however
> fully intermingles them. Which directories are to be aliased could be
> a vendor-specific configuration and should be encoded as such. That
> kind of separation of concerns has not happened at all.
>
> It should also be noted that the patch describes itself as
> incomplete. No attempt at completing it seems to have been made thus
> far.
It is a proof of concept patch, so I'm not surprised it doesn't address
this. However, I suspect people won't feel motivated to address issues
if the dpkg maintainer(s) just says "it's totally broken". Given the
history of multi-arch patches, this seems to lead to a quite un-
enjoyable process.
> In
> principle, the technical merits seem solvable to me, but the total
> failure on the process level leaves me wish for a revert.
If you want to turn back the wheel a few years and restart this
discussion again, please open a tech ctte bug now or file a GR.
Please also engage with upstream projects that do no longer want to
support split-/usr to maintain the support there. Ideally also
establish something to make sure we don't miss hardcoded paths that
only work on usrmerged systems (e.g., udev rules, not always called
code paths in programs, ...).
If you don't want that solution, please don't suggest it repeatedly:
it's non-motivating to spend any further time.
> The communication is clearly
> failing on both sides, which is why we're here at the ctte again.
Sure, it fails.
And the tech-ctte process is painful again too: we need at least a
month-long discussion even about just the current postinst warning even
though I've seen not many people aggreeing with having it: at least one
ctte member objected to a proposal to vote on this sooner.
Ansgar
Reply to: