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

Re: Do we want to Require or Recommend DH



Sean Whitton writes ("Re: Do we want to Require or Recommend DH"):
> I agree with Scott's emphasis on the distinction between new and
> existing packages.  Perhaps application of the distinction could be
> extended: perhaps there are other things that we could require of new
> packages, while creating no expectation that these requirements be met
> of older packages.
> 
> In general, if a policy requirement or convention should apply to new
> packages, then it should apply to existing packages, too.  But
> specifically where applying the requirement to an existing package is
> hugely more work than applying it to a new package, perhaps the
> requirement ought to be limited to new packages alone.

There is a big distinction between recommendations which directly
affect the functioning of the binary packages, and recommendations
which make future development easier.

For the latter - and use of dh is an example - it makes a lot of sense
to make the recomendations stronger for new packages.

I also think it would be very valuable for policy to recommend things
like this as the usual case, without mandating them.  If for any
reason the maintainer doesn't want to use dh, then they can leave a
wontfix bug open (or something) to document the reasons.

My own anecodote:

Last year I converted src:xen to dh from the previous baroque system
(which I think was based on a clone-and-hack of the machinery in
src:linux.)  The result is massively better.

But it was serious work to repeatedly debdiff the results, review each
individual weird thing and decide whether to keep it, try to reproduce
its effects with a dh override or whatever, etc.  This needed a high
level of familiarity with both the underlying software and Debian's
packaging practices.  Even so I caused a handful of regressions.

One thing that I found really good about dh is that you only have to
write code about things that are unusual.  This provides an excellent
opportunity to leave a comment next to each weird thing explaining why
it's there.
  https://browse.dgit.debian.org/xen.git/tree/debian/rules#n111

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.


Reply to: