[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 at 06:48:32PM -0500, Manoj Srivastava wrote:
> >>         Is this so very different from what people do? Some times I  do
> >>  not package every upstream version, if they are coming in rapid
> >>  succession, or if I find some version unfit for Debian -- but in any
> >>  case, the majority of the time I want to package the very latest
> >>  upstream version.

> > The difference is having a get-orig-source that works for the majority
> > case (I want to package the very latest), instead of working for all
> > cases (I want to package upstream version $x, which may or may not be
> > the latest).

>         How do you propose that one specifies "get and munge the latest
>  source" when one might not know a priori what the version number might
>  be? The interface spec of this target that works for all cases is not
>  very clear to me. Does a missing verion mean I want the latest? Or that
>  I want to use the version in the Changelog? I had imagined that he
>  current language in policy that says get the /latest/ was at least
>  unambiguous on this, but I seem to have been in error.

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.

>         Does it make sense to have more than one target? Should it be a
>  target in rules, as opposed to a script in ./debian? The advantage of a
>  separate script is that it is easy to check if the script exists
>  (whether or not a Make target exists is hard to determine), and it is
>  easier to communicate options to a script.

I personally have a pretty strong preference for this being done in
debian/rules rather than as a new script in debian/.  I find my debian/
directories become cluttered enough with stuff not standardized in Policy,
without adding new Policy requirements to them. :)

>         I can see that we can have get-orig-source-latest and
>  get-orig-source-current scripts in ./debian, and would prefer that to
>  overloading a single make target, with all the hassles of passing
>  arguments in env variables.

I think that's inelegant because it implies code duplication between the
scripts, one script calling the other, or both scripts including code from a
third file.  A debian/rules target (or two) can avoid all of these issues.

On Thu, Mar 12, 2009 at 10:31:07AM -0500, Manoj Srivastava wrote:

>         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.

I think it might be instructive to find out how many packages in the archive
actually have conformant get-orig-source targets.  If the number is small, a
Policy flag day might in fact be the simpler approach anyway.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Reply to: