On Sat, Oct 06, 2007 at 10:37:48PM +0000, Colin Watson wrote: > The second possibility seems to me to be more flexible, though, and > probably not all that hard to implement: build both a .tar.gz > (containing the working tree) and a .$VCS.tar.gz, and teach 'dpkg-source > -x' to unpack the tree given at least one of these. This would allow > various interesting possibilities such as:
Would this be better in any way than having a web interface that provides
an autogenerated version-1 source package? Presume it's a url like:
http://v1source.qa.debian.org/i/ifupdown/ifupdown_0.6.8.dsc
> * Buildds could just fetch the .tar.gz; they have no need of the VCS
> data. Users who just want to inspect the current version of the
> source and not change it might want to do this too, using (say)
> 'apt-get source --no-vcs package'.
dget -x http://v1source.qa.debian.org/i/ifupdown/ifupdown_0.6.8.dsc
> * Developers on slow connections could say 'apt-get source --vcs-only
> package' to fetch just the .$VCS.tar.gz, with the documented caveat
> that it would be just like checking the source out of a VCS in that
> you might have to recreate some autogenerated files.
That happens automatically.
> * Space-constrained mirrors could conceivably exclude the VCS data if
> they had to, though we probably wouldn't encourage this.
Mirrors wouldn't mirror the autogenerated stuff, so not an issue.
> * Derivative distributions who are slow to upgrade their dpkg-source
> could still interoperate to some degree.
They'd need to pull sources from the autogenerated url; though they'd
still probably have Build-Depends: issues if they're not updating
packages generally.
> * Tools like mc, vim's tar plugin, or
> http://www.mirrorservice.org/sites/ftp.debian.org/debian/ could
> still be used straightforwardly and without modifications to look
> inside source packages on mirrors.
Again, you'd have to go to the autogenerating url rather than a mirror.
Cheers,
aj
signature.asc
Description: Digital signature
