On Sat, Oct 06, 2007 at 11:19:43AM -0400, Joey Hess wrote: > Anthony Towns wrote: > > Changes in repository formats will presumably result in versioned > > dependencies too. > I don't think that dpkg should add vcs formats that we don't have a good > expectation of remaining supported by newer versions of the tools going > forward (so svn repos are out). It's more that newer versions of the tools will create more optimised repo formats, that older versions don't support -- bzr has done this between etch and lenny, eg. My inclination would be to have dpkg support it, but have it generate a REJECT at upload time if we don't want to support the new format (yet). > If the format changes in a non-backwards compatible way, we could have > source packages built on unstable that cannot be extracted on stable, > which I also think is suboptimal, but hard to completly avoid. Well, that's true of any Version: 3 format already anyway. > > Once the unpack is done, I don't see any reason why you can't do an NMU > > in the traditional way, so presuming "dpkg-source -x" or "apt-get source" > > handles the unpack automatically, I don't think it necessarily imposes > > any new requirements on NMUers. > Basically, you have to know how to git commit your changes before building > the NMU, and that's all. As a bonus, it's rather easier to generate NMU > patchsets. :-) Well, there's two options: - dpkg-source knows it's "meant to be" a git package, and can either warn you you have uncommitted changes (and tell you what to do) or just auto commit them for you - dpkg-source doesn't know what sort of package it's meant to be and just builds a v1 source package Both of which sound pretty trivial for an NMUer to deal with... > > Maybe providing a feature on packages.debian.org (or similar) to download > > sources in simple, non-VC, tarball format would make this a complete > > non-issue though? > pristine-tar could be used for this, it would just need source packages > to put the delta somewhere standaised (under debian/), and would need > some standarised way to get to the upstream source branch in git. So the logic there would be: if there's an upstream tag, then generate an .orig.tgz if there's a pristine-tar info, hax0r it to be pristine generate a .diff.gz if the .diff failed goto bailout generate a .dsc containing the orig and diff publish all three else: (bailout:) generate a .tar.gz generate a .dsc containing the tar publish both > > Would it make sense to have the source format look more like: > > Format: 3.0 > > Source: dpkg > > ... > > Source-Depends: git-dpkg (>= 3.14159) > > Source-Hooks: /usr/bin/git-dpkg > > ... > > Files: > > ... foo_1.2.git.tar.gz > > You could drop the Source-Hooks: line, and just have dpkg-source know > > to associate *.git.tar.gz with /usr/lib/dpkg/source/git, and trust the > > package will provide it. > Not sure if this buys anything that using perl modules for the vcses > can't do, really. It doesn't buy anything extra, so forget the Source-Hooks: and just consider it to be a different package providing the VCS-specific perl module. That buys you: - no changes to dpkg to support new source formats - easy for other distros to support more or fewer VCS formats - version info to deal with new repo formats - explicit dependency info that can be checked at upload time to block source formats we don't want to support > How do you envision this helping deal with repository > format changes? Repo formats that bzr in etch can unpack could be denoted by Source-Depends: dpkg-bzr (>= 0.11) while repo formats that require bzr from lenny or later could be denoted by: Source-Depends: dpkg-bzr (>= 0.18) (Or you could have a versioning scheme that matches the repo format directly, rather than the program being used. Or you could use virtual packages and say dpkg-bzr-v3 and have that be Provided: by some package/s, etc) It'd be straightforward to make a policy decision to only ACCEPT uploads with given Source-Depends: lines, eg ones that can be satisfied using packages from stable, while letting third party repos experiment with new repo formats without needing to use a different dpkg than Debian does. Cheers, aj
Attachment:
signature.asc
Description: Digital signature