On Thu, Mar 12, 2009 at 08:49:19PM +0100, Bernd Zeimetz wrote: > No, please don't just add another watch file just for the sake of it, using > these files is more or less like living in the last century. People are able > to > get the current source from the Debian pool, if that is not enough for them, > they should be old enough to be able to click on the upstream homepage link in > the package's description and get the source.
> A lot of people, including myself, prefer to pull form the upstream vcs > directly, and work on top of that, using git for example. Using uscan to > retrieve the exact version is often impossible, as it's not trivial to get > a tarball from a specific upstream branch, tag or ref. I'm not sure if you're arguing against using get-orig-source this way or just arguing against a watchfile-like approach, but I would say that's precisely the case that the get-orig-source target is intended for. Cases where generation of the tarballs used as .orig.tar.gz in Debian is non-trivial are cases where the process of generating these tarballs should be documented in a machine-automatable manner, whether they're generated by downloading an existing upstream tarball and munging it, or by pulling from a particular VCS tag. In an ideal world, we would have a standard method for recreating a tarball from upstream that doesn't assume familiarity with any particular VCS, or familiarity with any particular upstream's tagging conventions. > I think the way Debian should go is to tell people that they should clone > the developer's git ([.. insert your favourite dvcs here ...]) repository > and work with it, probably requiring to explain how working with the > repository works, which branches are used for what, and so on. At least > that would fit *todays* way of handling packages, at least for a lot of > people. Wrong for the various reasons Russ has already given - and also because <insert your favorite dvcs here> gives us no common format that all Debian developers agree to use. The value in having such targets in policy is so that developers *other* than the maintainer can rely on them. -- 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
