Re: Bug#466550: Pristine source from upstream VCS repository
On Thu, Mar 12 2009, Steve Langasek wrote:
> On Wed, Mar 11, 2009 at 10:13:51AM -0500, Manoj Srivastava wrote:
>> This is what diferentiates is from uscan; indeed, I use uscan in
>> the cases where I provide the target, The target unpacks the
>> raw upstream source, munges it (by, say, removing a subdir which has
>> non-dfsg stuff, or removes the debian dir, applies patches, or whatever
>> other processing is required.
>
>> There is no need to do this for the current version; the mungeds
>> sources already are an apt-get source away.
>
> For several packages I (co)maintain where I have to munge the upstream
> tarball, the standard procedure (inherited from past maintainers) is:
>
> - increment the version number in the debian packaging
> - call the get-orig-source target
>
> I think it's perfectly reasonable to want the get-orig-source target
> to give you a *specified* version of an upstream tarball, rather than
> the *newest* version of an upstream tarball. Packaging a new upstream
> version doesn't necessarily mean packaging the latest that uscan can
> find.
Fair enough. But that is not the semantics of the target
currently: get-orig-source is defined right now to get the /latest/
source, and while it is reasonable to have both behaviours, it is not
necessary to expect both from the same target.
To recap:
1) apt-get source is enough to get the latest Debian source from the
archive (and whet for older sources)
2) In the absence of munging, uscan, with a watch and watch-current
files, is adequate to get either the latest or a specific version
from upstream
3) It is reasonable to get the latest, or a specific version, from
upstream, and munge it.
So, for case 3: get-orig-source has been defined to get the
latest sources (with munging, if needed). If we want to get a specific
version, we can:
a. over-load get-orig-source to take a version number, some how,
through an env variable, perhaps
b. create a brand new target, which looks at the env variable, and
falls back to the version in the changelog.
I think case a is harder from a policy creation perspective,
since it should not outlaw currently conforming implementations. The
new target method can be deployed, tested in the wild, and then made
into policy when the kinks have been ironed out.
manoj
--
Writing is turning one's worst moments into money. J.P. Donleavy
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: