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 interactivly 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 does. Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
