[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] proposed v3 source format using .git.tar.gz

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
		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

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,

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.


Attachment: signature.asc
Description: Digital signature

Reply to: