Re: [PATCH] proposed v3 source format using .git.tar.gz
Anthony Towns wrote: > > 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. > > Maybe you could do a "git branch dpkg-build.$UUID", commit in the branch, > generate the .git.tgz, then drop the branch? Ah, now I understand what Frank was getting at. Only problem I see with a temp branch is the source package would be shipped using this funky branch name. -- see shy jo signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Feb 10, 2008 at 10:08:58PM +0100, 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. Wow! Exciting times! > 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. Maybe you could do a "git branch dpkg-build.$UUID", commit in the branch, generate the .git.tgz, then drop the branch? > 3) About the plugin interface: I was considering whether it would be > better to move the tar generation into the plugin itself. This makes sense to me -- it seems like the logical conclusion of Joey's original vies of the orig+diff as a version control system. If everything's a version control system, then we should just need a plugin architecture for distributing source via a version control systems, and use it for everything. > 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). I wasn't even thinking substvars, I was thinking the plugin would just have a constant string that would be used for Source-Depends. Newer versions of the plugin might update the string, to deal with newer versions of the underlying repository format, but that's it. The two advantages of that that come to mind are it lets apt ensure you have everything you need to unpack before downloading anything (rather than download, try to unpack, upgrade, successfully unpack), and it gives dak something easy to REJECT on if we want to avoid having sources in unstable that can't be unpacked with git/bzr/etc from stable. Cheers, aj signature.asc Description: Digital signature
Re: [RFC] Enhance checksum support
On Sun, Feb 10, 2008 at 06:46:55PM +0100, Frank Lichtenheld wrote: > On Tue, Jan 29, 2008 at 04:06:12PM +1100, Anthony Towns wrote: > > On Sat, Jan 26, 2008 at 10:14:56PM +0100, Frank Lichtenheld wrote: > > > The whole thing honestly doesn't do much for security anyway until the gpg > > > support of dpkg-source is largely improved. For that I have no real > > > concept > > > yet, though. > > Well, apt verifies them when it downloads the source before passing > > it to dpkg to unpack; and there's also verification when entering the > That would be news to me. And I can't seem to find that in the code, > either. $ apt-get source dpkg Reading package lists... Done Building dependency tree... Done Need to get 3385kB of source archives. Get:1 http://blah stable/main dpkg 1.13.25 (dsc) [853B] Get:2 http://blah stable/main dpkg 1.13.25 (tar) [3385kB] Fetched 3385kB in 10s (334kB/s) Failed to fetch http://blah/debian/pool/main/d/dpkg/dpkg_1.13.25.dsc MD5Sum mismatch E: Failed to fetch some archives. Cheers, aj signature.asc Description: Digital signature
Re: [PATCH] proposed v3 source format using .git.tar.gz
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 signature.asc Description: Digital signature
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 , > 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]
Re: [PATCH v3] Enhance Checksums support
On Sat, Jan 26, 2008 at 11:39:13PM +0100, Frank Lichtenheld wrote: > So this is the version of the patch that implements aj's suggestions. > I still like my format better, but really only for aesthetic reasons. After procrastinating about that a bit I changed my mind. The similarity with the Releases files and the old Files field plus the argument that in this format it is really easy to verify the files I will use aj's format. 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]
Re: [RFC] Enhance checksum support
On Tue, Jan 29, 2008 at 04:06:12PM +1100, Anthony Towns wrote: > On Sat, Jan 26, 2008 at 10:14:56PM +0100, Frank Lichtenheld wrote: > > The whole thing honestly doesn't do much for security anyway until the gpg > > support of dpkg-source is largely improved. For that I have no real concept > > yet, though. > > Well, apt verifies them when it downloads the source before passing > it to dpkg to unpack; and there's also verification when entering the That would be news to me. And I can't seem to find that in the code, either. > archive in the first place, and manual verification at other times (eg, > when the archive gets compromised). 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]
ebuild
Hi, do you know it it exists something that allows to create .deb packages from ebuilds (or others files that looks like ebuilds)? Can dpkg manages other package formats than .deb? Thx. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
