Bug#994388: dpkg currently warning about merged-usr systems
On Thu, 24 Mar 2022 18:56:54 +0100 Helmut Grohne <helmut@subdivi.de> wrote:
> On Thu, Mar 24, 2022 at 09:31:21AM -0700, Sean Whitton wrote:
> > We should distinguish two senses of "supported".
> >
> > There is the sense of what Debian-the-project supports. That is
> > specified in the TC decision. That is not subjective.
>
> This could be a language issue on my side. As I see it, the Debian
> project clearly endorses merged-/usr. I have difficulties calling it
> support, because that would go in hand with fixing the resulting
> problems - which is not happening. In my reading, support is an activity
> rather than a statement. That activity is missing. I even ran into
> /usr-merge fallout in 2022 myself. The statement is clear enough and
> Guillem's warning is clearly not helping the state of affairs.
>
> > The difficulty is that Guillem's warning kind of refers to both.
>
> Yeah, I see how you get there. It is fully in line with the confusion I
> see elsewhere.
>
> Let us try to turn this upside down: How can Guillem express his
> dissatisfaction with the current process in a way that does not cause
> harm? Guillem has to deal with quite a number of /usr-merge-caused bugs.
> Many of them lack patches and/or are duplicating existing ones. In cases
> patches were posted (e.g. dpkg-shlibdeps), Guillem has included them.
There are two separate issues here: dissatisfaction with Debian's chosen
approach to the /usr-merge issue, and dissatisfaction with dpkg not
natively supporting Debian's chosen approach.
For the former, that decision is made, and while anything can be
*discussed* and a new decision could theoretically be made in the
future, that doesn't change or invalidate the decision as already made.
Delete the "usrunmess" script and most of the contents of the Dpkg
usrmerge "FAQ".
For the latter, that's *absolutely* reasonable. Even if (as extensively
discussed) larger issues don't tend to arise in practice, there are real
issues such as `dpkg -S` not handling search paths as expected (`dpkg -S
/bin/ls` vs `dpkg -S /usr/bin/ls`), as well as issues making it harder
to migrate packages to "natively" have files in /usr eventually. And if
users are filing bugs about such issues, it'd be entirely reasonable to
close or merge such bugs, referencing to one or a few bugs tracking the
lack of usrmerge support.
It would also be entirely reasonable to call for help fixing such
issues. It's entirely possible that someone would have written dpkg
patches *already*, if the pitched battles over usrmerge hadn't made it
abundantly clear how such patches would be received (and, at the moment,
likely *still* would be received). I think that has unnecessarily
delayed any efforts to actually help with this.
The maintainer script was not such a call for help, at all. And it has
already caused harm, and is continuing to do so.
As it stands, I think the path forward would be:
1) Delete the message from the maintainer script, immediately, and
upload a new version of dpkg with that message removed. Don't add any
new such user-targeted messages in that or other places (e.g.
Description).
2) Issue a call for help *supporting* the established approach to
usrmerge, not subverting and relitigating it.
2.1) Make it clear that dpkg patches to fix issues related to
usrmerge, as well as updates to the documentation (including the
wiki), will not be unreasonably blocked on the basis of dislike
for usrmerge. (This will be necessary to make (2) successful.)
3) Delete `dpkg-fsys-usrunmess`.
4) File one or more bugs, or select existing representative bugs that
don't have too much noise in them, about dpkg support for usrmerge
(ranging from `dpkg -S` to the handling of files moving from / to
/usr to the handling of file conflicts between packages).
5) Close or merge any new and existing dpkg bugs about merged /usr,
pointing to the appropriate representative bug(s).
I think it would be appropriate for the TC to issue a ruling regarding
points (1), (2.1), and (3) above, and optionally to issue advice
suggesting (2), (4), and (5).
Reply to: