Hello, On Thu, Jul 05 2018, Russ Allbery wrote: > 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). Indeed, this is how Policy could address Andreas' concerns. Thanks for writing it up, Russ. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature