On Sun, Nov 27, 2011 at 12:01:53PM -0400, Joey Hess wrote: > Stefano Zacchiroli wrote: > > having worked quite a bit on "mediating" the wishes of Debian (as > > upstream) developers with those of downstream derivatives, I feel > > confident stating that many people in Debian would now welcome being > (I assume you made a significant typo --------> not)
I did indeed. s/not/now/ is a recurrent typo for me, but that doesn't
make it less embarrassing (especially in this context).
> Divergence in debhelper between debian derivatives results in packages
> that will build in distro A but not in distro B, with no indication why
> beyond a dh_ command being missing or not working as expected. This is
> severely bad for the greater Debian ecosystem, to borrow a term.
I agree with this.
> I have pointed out this is a problem before, and have been roundly
> ignored.
I was not aware of this. Not that I should have been informed but, with
your permission, I'd like to help now. My motivation to do that is that
I believe having you ignore the two bugs we're discussing is bad for
Debian, and not only for the so called ecosystem. Mind sharing with whom
you pointed out the problem in the past? (even in private mail / IRC
query, if you prefer)
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.
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.
Thanks for your feedback,
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
