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: