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/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
