Bug#515856: debhelper: please implement dh get-orig-source
Simon McVittie <smcv@debian.org> writes:
> If this is reinstated, please can we discard the requirement that
> get-orig-source be invokable with an arbitrary working directory? Many
> packages don't do that (because it's much more difficult to achieve than
> it looks), so clearly nobody is actually able to rely on it.
I think a compelling reason to get rid of the Policy specification of
get-orig-source is that the specification has proven to be incomplete and
inconsistently implemented, so you don't really know what you're going to
get when you invoke it. (Usually just an error that the target wasn't
found.) The people who can therefore effectively use it are either the
maintainers of that package who know what it does, or people who have read
some package documentation like README.source that explains how to use it.
And neither of those audiences need Policy to mention it.
Think of it this way: what behavior do we enable by including the current
paragraph about get-orig-source in Policy that would not be available if
Policy were just silent about it?
I think the original hope was that you could download a random Debian
source package and then run debian/rules get-orig-source to get the
tarball on which to base an upgrade to the latest Debian version. But I
don't think this has panned out in practice, and uscan is now far more
sophisticated and a better way to achieve this (plus has much larger
archive coverage). For instance, get-orig-source would require one to
implement their own checking of upstream source signatures, whereas this
can be easily automated with uscan.
> In my own packages that have a get-orig-source (mostly those where I
> have to use git snapshots or delete large non-free subtrees or both), I
> usually end up implementing a maintainer-get-orig-source target that
> wraps get-orig-source to make it work the way I want it to.
To me, this is a clear sign that get-orig-source is not useful as Policy
currently documents it.
The common case where get-orig-source might work out of the box is already
handled with uscan, which is better-documented and more widely
standardized. For the remaining weird cases, Policy's description was not
all that helpful, and maintainer-focused custom targets or tools plus
documentation in README.source seems like the best approach. For example,
if you have to repack upstream source in complicated ways, it's quite
possible you'll need to adjust that repacking with new upstream versions,
which means you need some documentation somewhere anyway and
get-orig-source in isolation isn't enough.
That said, the current description of README.source focuses on how to
modify the package. Maybe it would be worth explicitly saying that how to
repack new upstream source should be documented in README.source if it's
not obvious how to do so?
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: