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