Andreas Tille <andr...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
