On Tue, 2022-03-29 at 08:24 +0200, Helmut Grohne wrote: > Hi Luca, > > On Mon, Mar 28, 2022 at 10:24:03PM +0100, Luca Boccassi wrote: > > Also worth noting that a couple of days ago, the author wrote on > > #debian-devel that some time ago the patch was presented to the dpkg > > maintainer, who rejected it with an answer along the lines of the usual > > "usrmerge is broken by design", with no further comment. > > 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.
Well, of course it's incomplete - if it is as it appears to be and the maintainer refuses to engage in any way, how can any reasonable progress be made? Especially in the fact of constantly shifting goal posts. First a working patch was needed to make progress. Now it's a patch that is working, perfect, and satisfies arbitrary and unspecified 'purity' requirements that are left mostly unstated and need to be specified by third parties, before the patch can be even looked at. I wonder what will be next... > > So, what is the next step? Will the those on this thread who asserted > > they think a correct patch would be accepted without issues try and > > take it forward themselves? > > I don't think anyone claimed that incomplete patches would go in without > issues. Much to the contrary. My experience with sending patches to > dpkg is that they do go through multiple rounds due to high quality > feedback. The problem I see here is that communication between patch > author and dpkg maintainer does not work and thus no progress is being > made. To be honest, the current form of the patch is a testament of how > poorly the /usr-merge proponents have spent the last five years on an > issue that was known for more than ten years. > > The more and more I have to deal with the /usr-merge the more I get > disappointed by how badly this transition is planned and carried out. In > principle, the technical merits seem solvable to me, but the total > failure on the process level leaves me wish for a revert. I am really > surprised that instead of improving the process, you carry on with that > destructive attitude. Given this, it seems unsurprising that Guillem > does not want to interact with you. Of course that's not an excuse for > implementing the recent changes to dpkg. The communication is clearly > failing on both sides, which is why we're here at the ctte again. > > The way I see it is that changes need to be well supported regardless of > how superior their technical approach is. If that's not the case, we > should not have that change and continue using what has worked in the > past. I'm sitting on such a change on my own and do not trying to push > it into Debian hard even though I am strongly convinced of its > superiority, because doing so would impose unreasonable cost on others. > There is a social aspect here that is presently failing hard. > > Helmut You say "how badly this transition is planned and carried out", and yet there is tangible proof that it is in fact working fine for all intents and purposes, without any major issues, for years and years. Again: default for new installations in the past two stable releases, default and forcibly transitioned for the past two Ubuntu releases (well, one past and one coming next month), plus every other major distro doing the same thing, in more or less the same way. The only observed issues are minor or solved long ago, or theoretical. In fact, the only widespread system breakages that are currently known to have happened were caused by the misleading dpkg postinst that was added some days ago. And all of this despite obstructionism from the maintainer of the involved package. To me this looks like a remarkably successful endeavour, all things considered. Of course it could be better if collaboration rather than obstructionism was happening. And the end result would have undoubtedly been better on a technical level. But this is a social issue, not a technical one - the CTTE made a decision (3 times) and a single maintianer is vetoing it and actively working against it, because they don't like it, since day one. How could proponents of the change do anything about it in this situation? What would you realistically do differently? -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
