Frank Lichtenheld wrote: > 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. Excellent. I had kept it merged to master, but haven't checked that it's not bit-rotted lately. > 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. Sounds like git stash? However, stashing away uncommitted changes and not including them in the build violates least suprise. I'd except to see them either commited automatically, or the current error forcing me to resolve them before building. The advantage to auto-committing, of course, is that you don't have to know how to use git (or debcommit) to build a package that uses it. > Prompting the user for the commit message would probably be best but > would break if people try to run the program non-interactivly. I don't think it's a good idea to prompt for a commit message. > 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 Not sure sure what you mean here? > 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. That would of course be fine. I didn't want to touch doing that in my branch for obvious reasons. :-) > 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. One appoach would be for dpkg to build a dpkg-dev-git package that includes the git format (and depends on git-core), and so on, then "Format: 3.0 (foo)" could be converted to dpkg-dev-foo. -- see shy jo
Attachment:
signature.asc
Description: Digital signature