[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Standardization, large scale changes, innovations

Wouter Verhelst <wouter@debian.org> writes:

> The same is true with Manoj. You may think debhelper is the best thing
> since sliced bread (it might be), but Manoj just disagrees. And as long
> as Policy does not specify that debhelper is to be used, it's perfectly
> within his right to not use it. As long as the result is good -- a
> working, policy-compliant package -- how he gets that result is not your
> business.

> If you think otherwise, you should first get Policy changed, and then
> complain to Manoj.

Also, as a general rule of thumb, Policy should be about standardizing
interfaces, not about standardizing tools.  What matters from a Policy
perspective is what ends up on the system, what ends up in the package,
and how the packages interoperate for the end-user, not how you create
them.  So from that direction, I'm not sure it would ever make sense for
Policy to require debhelper.

To the extent that Policy already does this in a few places, I think it's
a bug, since among other things it makes it much harder to figure out
what's really going on and it makes it harder for subsequent tool authors.
If someone thought there was some much better design for how debhelper
does things and wanted to start from scracth writing a new helper, they
should be able to find documentation explaining what interfaces they need
to satisfy, ideally.

The major exception to this right now is that Policy assumes dpkg and the
core dpkg tools (not the dpkg-dev tools necessarily) like dpkg-divert.  I
personally think this is a bug and I'd like to see the low-level
documentation of the exact deb format, for instance, in Policy, but it's a
very low priority compared to lots of other Policy work.

Now of course if one orphans one's package or can't maintain it properly
(lots of RC bugs, etc.), then I think redoing the packaging design is fair
game once QA comes into play.  Were Manoj to orphan a package, I suspect
it's quite likely that whoever picked it up would convert it to debhelper,
and that's fine.  If I adopted a package maintained in bzr, one of the
first things I'd do is convert the VCS repository to Git.  But as long as
the package is staying with its current maintainer and that maintainer is
doing a good job, I think the obligation of that maintainer is to satisfy
the interfaces, and what tools they use to do that is their business.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: