On Mon, Mar 16, 2009 at 12:08:56AM -0500, Manoj Srivastava wrote: > >> Given that we already have a tool that can download upstream > >> sources, with or without mangling, and can be used by facilities > >> outside of the unpacked Debian source package to determine if there was > >> new versions and to download unmangled versions, is there any need to > >> retain the get-orig-source target at all?
> > I have get-orig-source targets that verify the upstream detached gpg > > signatures before repacking the tarballs. Is there a way to do that with > > uscan? > There is no limit on what your user specified script can > do. Given a version number, you can still download the hash and test > it. No sweat. So I have to duplicate information (the upstream URL) between the watch file and the script? Seems like it's better to just continue using get-orig-source then. > >> I mean, this seldom implemented target is duplicating an existing and > >> widely used facility in Debian; and removing the target from the policy > >> will advance the laudable goal of stripping the policy of cruft. > > Well, I doubt more people are using uscan mangling than are using > > get-orig-source, really; so I don't think that facility is "widely used". > There are far many more watch files in packages than there are > get-orig-source targets in rules files, so yes, uscan is far more > widely used. As I said elsewhere in this thread, mangling is not widely > enough automated to say anything one way or the other about practices > followed. It certainly is possible to say which of the two possible processes for mangling is more prevalent by examining the archive. $ cd /srv/lintian.debian.org/laboratory/source $ find . -mindepth 3 -maxdepth 3 -name rules | xargs grep -l get-orig-source | wc -l 752 $ There are many more watch files than that, of course, but how many of them include non-default actions? I'm pretty confident that it doesn't approach 5% of the archive, even without subjecting gluck to a script to parse all the watch files to check this. > I would not be against a recommendation in policy to implement > direct-from-vcs upstream tarballs to be created vbia get-orig-source, > and everyone else just use debian/watch and debian/urepack files. The (as-yet-unrealized) benefit of having this defined in policy is to give developers other than the maintainer a simple, standard way to grab the new upstream source of a package. Doesn't "try debian/rules get-orig-source, and if that doesn't exist, try uscan instead" fall short of "simple"? (This is basically the status quo, so it's not a tragedy if we don't correct it - but if we're going to amend policy here anyway, surely it would be good for the outcome to be a policy definition that meets this standard.) On Fri, Mar 13, 2009 at 10:38:35AM -0500, Manoj Srivastava wrote: > 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). Popularity speaks to whether developers find it useful. We shouldn't be codifying requirements into Policy if it doesn't actually benefit us to standardize on them. But if there is a benefit from having all packages behave the same way - "integration issues", as you say - that should be weighed against incompatible minority workflows. I certainly do think that the inclusion of get-orig-source in Policy serves no purpose *but* to provide a consistent interface that developers can rely on. So while we should try to minimize the disruption of maintainers' existing workflows, if this belongs in Policy at all (which I believe ultimately it does), then that trumps the fact that some packages will need to change in order for their maintainers to continue using their preferred workflow. -- 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-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org