Re: get-orig-source and standardized source repacking (was: Debian Policy 4.1.4.0 released)
Andreas Tille <andreas@fam-tille.de> writes:
> My main point is that README.source is just text and no code that I can
> run and test. That's different from my proposal.
I can definitely see the merits of clear automation the process of
transforming an upstream release into a tarball usable for Debian
packaging (with the caveat that like all packaging it may require
modification for a new upstream release).
get-orig-source was not that, partly because it was originally
underspecified and partly because people used it inconsistently to solve
two subtlely but significantly different problems (as Bill pointed out).
As a result, the get-orig-source targets in the archive are a mixed bag
and are not reliably (or, and I think this is important, testably) usable
for that purpose.
Reintroducing the same target with the same name but with a stricter
definition would almost certainly make a bunch of those packages buggy.
I'm dubious that it's worth disrupting whatever local workflow that they
already have around get-orig-source by asking them to rename that target
if it doesn't match with new semantics. That doesn't mean it's a bad idea
to have what you're asking for with clear semantics. However, I think the
best way forward is to have that be something new that has clear semantics
from the start.
For example, I think one promising way to look at this problem is to
define a way to transform a given upstream tarball into its corresponding
Debian source tarball, and then one can test that downloading the upstream
release corresponding to the current Debian source tarball and running
that process on it produces an equivalent tarball to the one used in
current Debian packaging. This is *not* what at least the get-orig-source
targets I am familiar with did.
I think the way to move forward with that is to write a specification that
clearly defines its scope and addresses the ambiguities discussed in the
original get-orig-source bug report, probably under some new name so that
we don't have the problem of making existing packages buggy and so that
it's clear whether packages are complying with the new specification as
opposed to inheriting some pre-specification get-orig-source target. We
can certainly then look at that for inclusion in Policy, although I think
it would be worth field-testing with a variety of packages first to make
sure a clearer specification is useful. There are a bunch of nasty edge
cases in this general problem, and while the specification doesn't need to
deal with all of them, it should be much clearer than get-orig-source was
about where it's declining to try to handle the problem and where
documentation for humans about the process should go (presumably
README.source).
Personally (although this certainly isn't a requirement), I think this
should build on the work that uscan is already doing and should probably
come in the form of uscan configuration or supporting scripts that uscan
would run automatically, to try to reduce tool proliferation and build on
the tool that's already solving 95% of this problem. (Or, alternatively,
a lower-level tool that uscan itself, as well as other tools like dgit,
can use, and that borrows from the work uscan has already done.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: