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

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

On Fri, Oct 05, 2007 at 07:16:13PM -0400, Joey Hess wrote:
> I have a sourcev3 branch with my changes at <git://kitenet.net/dpkg>,
> and have also attached a diff to this mail. I feel that this is ready
> for review and hopefully merging into dpkg now. Looking forward to your
> comments.

I've now added this branch to the "official" dpkg repository on alioth
with the intention to work on it. I've at least fixed it up so that
it works with the current code base.

After thinking a bit about this proposal I have the following
suggestions for changes that I would like to put up for discussion:

1) I don't really like the current behaviour when there are uncommitted
changes in the package directory. I would suggest as default behaviour
creating a commit containing these changes. This would eliminate the
need for people having to commit changes if they don't really care.

The most elegant solution would probably to create the commit, clone it
and then do a "git reset HEAD^" in the package directory. Don't know if
that is robust enough, though.

Prompting the user for the commit message would probably be best but
would break if people try to run the program non-interactivly.

2) Independently from the default behaviour on pack we should definetly add
a command-line option for the user to choose between the three
possibilities 1) error out, 2) create a commit, 3) create a commit

3) About the plugin interface: I was considering whether it would be
better to move the tar generation into the plugin itself. This would
allow other plugins more flexibility (e.g. generating more than one
file). My masterplan includes making source formats 1.0 and 2.0 plugins
internally ;)

This would of course require to move the tar generating and compressing
code to a module that can then be used by the plugins.

4) aj suggested in this thread to add a Source-Depends field which could
be used to specify the dependencies needed to unpack the package. I
guess that could prove useful, but I really would like to avoid that
all packages need to specify it (even though that might be solvable with
substvars defined by the plugin). OTOH if dpkg uses an internal
mechanism to map format to dependencies it would be more difficult for
other programs like apt to get to this information. Or is this all
over-engineering and the plugin should check its pre-requisites itself
and note the dependencies in the error message like the current code

Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/

Reply to: