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
Attachment:
signature.asc
Description: Digital signature