Stefano Zacchiroli wrote: > Still, I'd like to understand how we can avoid the problem in the > future. The two bug logs we are discussing concerns apparmor and > multi-arch. Both cases concern technologies that have been available > first in a downstream distro and only then, and recently, in Debian. > Would you have accepted to sign-off, and maybe even integrate, patches > about stuff not in Debian yet? We have examples of that happening with > Ubuntu, but the problem is more general that that; the higher the number > of derivatives we have the higher the potential occurrence of these > issues in the future. > > I think it's reasonable for you to ask to sign-off on debhelper changes, > but we need: (1) your willingness to accept changes that are potentially > not useful for Debian (yet), and (2) a way to inform derivatives of > that. Recent work on the Derivatives Front Desk about a "Debian branding > how to" can help with (2), but not with (1). > > > Note that if debhelper is NMUed, I will be stuck trying to maintain a > > package that contains code that I have decided not to have anything to > > do with. That could well end up being an impossible position for me to > > continue maintaining debhelper in Debian. > > That would be very bad. It's a sort of catch 22. I'm sure nobody would > want to lose you as debhelper maintainer. At the same time you're > applying your right to ignore specific patches due to their *past* > history. When the *present* of those patches is that they are useful and > needed in Debian, for Debian needs, not for the need of a derivative who > happened to ship them in the past. If you welcome an NMU, we have a way > out of it. If you don't, I honestly don't see which way out Debian has, > to get features we currently lack.
I appreciate what you're trying to do, but I simply have no interest in trying to deal with these problems further. I hope that whatever Debian decides to do lets me continue to maintain debhelper in Debian. > Would a clean re-implementation do? It seems silly to even think of > this as a way out when working code already exists, but it'd be better > than nothing. No, because my issue is not with the code but with Ubuntu continally forcing Debian to accede to their changes or risk horrible divergence. As we also saw with dpkg triggers, etc. -- see shy jo
signature.asc
Description: Digital signature
