Re: Bug#466550: Pristine source from upstream VCS repository
On Thu, Mar 12 2009, Steve Langasek wrote:
> On Thu, Mar 12, 2009 at 06:48:32PM -0500, Manoj Srivastava wrote:
>
> Oh, I think the existing language is perfectly unambiguous, I'm just saying
> that the behavior described doesn't seem to be what most/many maintainers
> want in practice, with the result that many packages implement
> get-orig-source targets that don't comply with this part of policy.
>
> As for how to specify "get and munge the latest source" - for my purposes,
> it's sufficient to do this by using out-of-band information about what new
> upstream versions are available, update debian/changelog (which has to be
> done anyway), and then call the debian/rules target. But if "grab whatever
> the latest version is" is also a common workflow, then perhaps a
> standardized make variable? e.g., './debian/rules get-orig-source
> version=latest', './debian/rules get-orig-source version=2.3.9', etc.
>
> OTOH, I'm not sure both of these cases need to be standardized in Policy,
> either. Certainly, the variation in semantics today means that none of
> these targets are particularly useful to third-party developers without
> first inspecting the debian/rules directly; and if the goal is to have
> something that third parties can rely on, I'm reasonably convinced that the
> "grab the version matching debian/changelog" approach is the one that's more
> broadly useful - because it's the one that matches my own workflow, because
> it's the one that I've seen others implement, and because it's the one I can
> think of a use case for in a QA/NMU context.
>
> But if it's useful to have both, I could be persuaded to provide a sample
> implementation that can pull either from the changelog or from uscan as
> described above.
Let me make a case here for the get-the-latest work flow, but
before I do so, I would like to state that the relative popularity of
the work-flow ought not to be relevant when making policy: technical
policy should not get in the way of even a minority work-flow without
sound and compelling reasons to select one method or the other (usually
this clause gets called in for integration issues). As far as
possible, policy should not attempt to proscribe work-lows (update
debian/changgelog before downloading new version vs update
debian/changelog after; so the git hash can be put into changelog
using dch). You know, tyranny of the majority and all that ...
Having said that, here is my case:
A) The vast majority of non-native packages in Debian do not need to
have their upstream tarballs mung3ed and repacked;
B) For most of these packages, if there is an upstream tarball at all,
uscan is adequate to get upstream sources,
C) The default for uscan is to get the latest sources,
D) The work that Debian developers do is mostly identical for packages
where upstream sources have to be repacked, once repacking is done
E) There are not enough examples of packages needing upstream tarball
munging to get a decent sample size for a statistical analysis
I would say that the default for get-upstream-with-munging
should be the same as our tool that gets-upstream-unchanged, namely
uscan.
Having said that, I would not object to a reference
implementation that uses a standardized make variable (but perhaps not
version; that is used in too many Makefiles for other things, perhaps
GOS_VERSION); and it would be nice that the default for GOS_VERSION was
'latest'. I would not object to a policy flag day either, because of
(E) above.
I will immediately start using it for sepolgen and fvwm :P
manoj
--
A man is already halfway in love with any woman who listens to
him. Brendan Francis
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: