[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

        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

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: