Hello, On Thu 24 Mar 2022 at 04:50PM -07, Russ Allbery wrote: > Josh Triplett <josh@joshtriplett.org> writes: > >> I think it's appropriate for people to wait on such work until there's >> guidance from the TC ensuring that such a patch will be accepted. >> Otherwise, anyone spending time writing it is spending substantial >> effort that may well be wasted. > > I think this is a totally fair thing to be concerned about. Should such a > patch exist -- with the obvious condition that I think it's quite > reasonable to do several rounds of iteration on making that patch solid, > ensuring there are tests, and so forth -- I think it's obvious that we > should merge it given the previous TC decision. Of course, I'm not a TC > member. > > It's difficult, procedurally, for the TC to do anything about a > theoretical patch that someone could write but hasn't written. > Particularly for dpkg, the details are important. I can think of some > ways of supporting merged-/usr that I wouldn't support even while > supporting the TC decision. We have various goals (such as being able to > bootstrap entirely through package installation) that can be met while > supporting merged-/usr but which do require design and care. > > If a concrete patch exists, the TC can (and has in the past) authorize an > NMU to apply it. Obviously, we should try to avoid reaching that level of > social and process confrontation if we can avoid it, but this is clearly > within the TC's constitutional power via a maintainer override, which puts > the discussion on somewhat firmer ground. But design of that patch is > *not* within the TC's constitutional mandate. > > It may be useful to look at how multiarch support in dpkg was handled. > That was quite painful and I really hope we don't end up following that > path exactly, but it provides a concrete example of how Debian's processes > can reach a resolution. > > I personally am still hopeful that we could do much better than the > multiarch outcome and find a patch that meets the architectural criteria > of the dpkg maintainer, but I'm fairly certain that we're not going to > make any progress towards that goal without having working code, or at > least a very detailed architecture, to start discussing and analyzing. This is how I see it as well. Putting aside the postinst warning, the I can't see anything the TC could do beyond what we've already done, until there's a patch on the table. Thanks for the summary. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature