On Thu, 24 Mar 2022 18:56:54 +0100 Helmut Grohne <hel...@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).