[pacman-dev] patch submission help
In the last month I have created and tested [1] a patch for pacman-3.2.2 that allows for 3 different PKGBUILD functions: build() check() inst(). This allows for a new option in makepkg.conf called check which is expected to default to !check (and overridden for toolchain packages). build() and check() are never run in fakeroot, only inst() (with exception for !fakeroot or --asroot, of course) which conforms to the fakeroot recommendation. My attempt was to make the patch backwards compatible so that if any of the functions weren't present, it was not an error. However, I realized while writing this email that this means that a PKGBUILD with just build() would run completely in a non-fakeroot environment which needs re-thinking. Anyway, it's a rather small patch as seen below: $ grep ^- makepkg.patch | grep -v ^--- |wc -l 16 $ grep ^+ makepkg.patch | grep -v ^+++ |wc -l 33 The reason for this email, though, is that I subbed to this list to watch how things are done, learn protocol, etc. So I grabbed the git repo and started looking at how I was going to apply this patch since enough has changed to cause all but 1 hunk to fail. I am not familiar with git, preferring svn, but can read docs. Where I'm tripped up is realizing that head doesn't reflect what private branches might hold. One person (sorry, I forget who) mentioned having a branch with many makepkg changes in it which would cause me to have to hand apply these changes again. I have no interest in doing that, so I'm asking: does this feature seem like it would be worthwhile (read; would the patch be accepted)? If so, how do I access private branches so my branch doesn't conflict with them? [1] I am building a base system with the new PKGBUILD format and am about 3/4 of the way done with no known makepkg errors (running makepkg with sh -x for extra detail) -- Jeff My other computer is an abacus.
Jeff wrote:
In the last month I have created and tested [1] a patch for pacman-3.2.2 that allows for 3 different PKGBUILD functions: build() check() inst(). This allows for a new option in makepkg.conf called check which is expected to default to !check (and overridden for toolchain packages).
build() and check() are never run in fakeroot, only inst() (with exception for !fakeroot or --asroot, of course) which conforms to the fakeroot recommendation. My attempt was to make the patch backwards compatible so that if any of the functions weren't present, it was not an error. However, I realized while writing this email that this means that a PKGBUILD with just build() would run completely in a non-fakeroot environment which needs re-thinking.
Anyway, it's a rather small patch as seen below:
$ grep ^- makepkg.patch | grep -v ^--- |wc -l 16 $ grep ^+ makepkg.patch | grep -v ^+++ |wc -l 33
The reason for this email, though, is that I subbed to this list to watch how things are done, learn protocol, etc. So I grabbed the git repo and started looking at how I was going to apply this patch since enough has changed to cause all but 1 hunk to fail. I am not familiar with git, preferring svn, but can read docs. Where I'm tripped up is realizing that head doesn't reflect what private branches might hold. One person (sorry, I forget who) mentioned having a branch with many makepkg changes in it which would cause me to have to hand apply these changes again. I have no interest in doing that, so I'm asking: does this feature seem like it would be worthwhile (read; would the patch be accepted)? If so, how do I access private branches so my branch doesn't conflict with them?
[1] I am building a base system with the new PKGBUILD format and am about 3/4 of the way done with no known makepkg errors (running makepkg with sh -x for extra detail)
Hi Jeff, The person with many makepkg changes on their branch would be me, but the vast majority have now been applied to the master git branch. Note that with the changes that are now in the pacmans git repo, there is support for build() and package() functions in PKGBUILDs. When the package() function is present, it is run under fakeroot but the build() function is not. Otherwise it is backwards compatible. I like the idea of an additional check() function. However, I could implement it slightly differently - instead of a makepkg.conf flag to run the check() function or not, I think it may be better to add a --check flag to makepkg so people specify when to run it. Anyway, I think the key point here is that if you have ideas for pacman/makepkg features and want to implement them, it is probably best to email here first to see what is already going on. Allan
On 17/03/2009, at 9:22 AM, Jeff wrote:
The reason for this email, though, is that I subbed to this list to watch how things are done, learn protocol, etc. So I grabbed the git repo and started looking at how I was going to apply this patch since enough has changed to cause all but 1 hunk to fail. I am not familiar with git, preferring svn, but can read docs. Where I'm tripped up is realizing that head doesn't reflect what private branches might hold. One person (sorry, I forget who) mentioned having a branch with many makepkg changes in it which would cause me to have to hand apply these changes again.
The typical centralized workflow is that contributers check out the "official" tree, create their patches, and then request to pull changes (via git-pull, emailing patches or other means). The nature of multiple people contributing at once is that things will get updated while you're working on something. Unfortunately the only thing you can do is fix it up and re-submit. Don't worry about what other people are doing, you should really be focusing on changes in the official tree. If you read that someone is making huge changes to something related to what you're working on then you could start basing your patches off them (this is the distributed part), if you're certain they will go into the official tree. It's just common sense really. As far as I can tell that workflow applies to Pacman development. In general try to have small commits locally. When submitting you can squash them into a bigger one (though if it's really big it's better to split them up sometimes). This could make it easier to fix up those commits later, since it's only a part of your changes would conflict (i.e., a few commits rather than all of them). Oh, and remember to use branches!
On Mon, Mar 16, 2009 at 9:28 PM, Sebastian Nowicki
On 17/03/2009, at 9:22 AM, Jeff wrote:
The reason for this email, though, is that I subbed to this list to watch how things are done, learn protocol, etc. So I grabbed the git repo and started looking at how I was going to apply this patch since enough has changed to cause all but 1 hunk to fail. I am not familiar with git, preferring svn, but can read docs. Where I'm tripped up is realizing that head doesn't reflect what private branches might hold. One person (sorry, I forget who) mentioned having a branch with many makepkg changes in it which would cause me to have to hand apply these changes again.
The typical centralized workflow is that contributers check out the "official" tree, create their patches, and then request to pull changes (via git-pull, emailing patches or other means). The nature of multiple people contributing at once is that things will get updated while you're working on something. Unfortunately the only thing you can do is fix it up and re-submit. Don't worry about what other people are doing, you should really be focusing on changes in the official tree. If you read that someone is making huge changes to something related to what you're working on then you could start basing your patches off them (this is the distributed part), if you're certain they will go into the official tree. It's just common sense really.
Yeah, that's the git concept that confuses lots of people at first. Don't worry about other people's trees (unless they're your base), only worry about the tree you want to get merged to. The one managing THAT tree should concern themselves with the merges (though, they may simply say: "can you fix this up so it merges cleanly after these changes?"). For project foobar, let's assume there are 3 people developing (bob, alice, and bruce) all with their own trees, along with one master tree we'll just call "foobar". One person should probably have "push" rights to foobar. That person will be the one managing which patches are pulled from the other two developers and pushed to the master tree. This is the way pacman rolls. Dan is the only one with push permissions to the master tree, and he pulls/merges/cherry-picks patches from the ML and from other people's branches and pushes them there
Aaron Griffin schrieb:
The typical centralized workflow is that contributers check out the "official" tree, create their patches, and then request to pull changes (via git-pull, emailing patches or other means). The nature of multiple people contributing at once is that things will get updated while you're working on something. Unfortunately the only thing you can do is fix it up and re-submit. Don't worry about what other people are doing, you should really be focusing on changes in the official tree. If you read that someone is making huge changes to something related to what you're working on then you could start basing your patches off them (this is the distributed part), if you're certain they will go into the official tree. It's just common sense really.
Yeah, that's the git concept that confuses lots of people at first. Don't worry about other people's trees (unless they're your base), only worry about the tree you want to get merged to. The one managing THAT tree should concern themselves with the merges (though, they may simply say: "can you fix this up so it merges cleanly after these changes?").
Some people don't seem to know about projects.archlinux.org. Jeff developed patches against pacman 3.2.2's makepkg, while similar changes already went into our master tree, which is located at http://projects.archlinux.org/?p=pacman.git;a=summary (URLs for cloning are also visible on that page). So maybe we should include in the PKGBUILD (that's where most people probably look when they want to get the source) a comment with a link to the master tree. I hope that this URL is already in the README from the source file as well.
On Tue, Mar 17, 2009 at 04:34:52PM +0100, Thomas Bächler wrote:
Some people don't seem to know about projects.archlinux.org. Jeff developed patches against pacman 3.2.2's makepkg, while similar changes already went into our master tree, which is located at http://projects.archlinux.org/?p=pacman.git;a=summary (URLs for cloning are also visible on that page).
So maybe we should include in the PKGBUILD (that's where most people probably look when they want to get the source) a comment with a link to the master tree. I hope that this URL is already in the README from the source file as well.
There's relevant information [1] in the pacman home page, which you will find with `pacman -Si pacman`. [1] http://www.archlinux.org/pacman/#_development
On Tue, Mar 17, 2009 at 10:17:19AM -0500, Aaron Griffin wrote:
For project foobar, let's assume there are 3 people developing (bob, alice, and bruce) all with their own trees, along with one master tree we'll just call "foobar". One person should probably have "push" rights to foobar. That person will be the one managing which patches are pulled from the other two developers and pushed to the master tree.
I appreciate you trying to help. I have worked with SCM for several years, but perhaps someone else reading this list hasn't and it is a good layout of how things work. My problem (and I think I worded it poorly) is that I didn't know if some of the branches that implement major changes were accessible to the public (read, Allen's branch). I'd rather work with that directly than flip a coin to see which of us gets a patch push first and which has to fix conflicts, especially since I'm an outsider. IOW, I'm treading lightly. :)
This is the way pacman rolls. Dan is the only one with push permissions to the master tree, and he pulls/merges/cherry-picks patches from the ML and from other people's branches and pushes them there
And I'm trying to keep both Dan and I from having to fix anything up. Conflicts are annoying. Huge conflicts are a downright nightmare. Oh, and I'm lazy. :) -- Jeff My other computer is an abacus.
On Tue, Mar 17, 2009 at 7:06 PM, Jeff
On Tue, Mar 17, 2009 at 10:17:19AM -0500, Aaron Griffin wrote:
For project foobar, let's assume there are 3 people developing (bob, alice, and bruce) all with their own trees, along with one master tree we'll just call "foobar". One person should probably have "push" rights to foobar. That person will be the one managing which patches are pulled from the other two developers and pushed to the master tree.
I appreciate you trying to help. I have worked with SCM for several years, but perhaps someone else reading this list hasn't and it is a good layout of how things work. My problem (and I think I worded it poorly) is that I didn't know if some of the branches that implement major changes were accessible to the public (read, Allen's branch). I'd rather work with that directly than flip a coin to see which of us gets a patch push first and which has to fix conflicts, especially since I'm an outsider. IOW, I'm treading lightly. :)
Everyone that has a regular flow of patches publishes them online, either with gitweb or better yet, via a URL git can fetch so you can see their stuff locally and diff and whatnot as you please: Master: git://projects.archlinux.org/pacman.git Mine (Dan): git://code.toofishes.net/dan/pacman.git Xavier: git://code.toofishes.net/dan/pacman.git Allan: http://dev.archlinux.org/~allan/git/pacman.git Nagy Gabor: git://repo.or.cz/pacman-ng.git I track all of these locally so I can do pulls and cherry picks of the various branches.
This is the way pacman rolls. Dan is the only one with push permissions to the master tree, and he pulls/merges/cherry-picks patches from the ML and from other people's branches and pushes them there
And I'm trying to keep both Dan and I from having to fix anything up. Conflicts are annoying. Huge conflicts are a downright nightmare. Oh, and I'm lazy. :)
You haven't used GIT long enough to realize that conflicts happen less, and are a whole lot less painful than with say CVS or SVN. The only case where they are truly terrible is when full file rewrites occur, or your patch does exactly what someone else's already did. -Dan
On 18/03/2009, at 11:23 AM, Dan McGee wrote:
Xavier: git://code.toofishes.net/dan/pacman.git
I think you meant git://code.toofishes.net/xavier/pacman.git.
participants (7)
-
Aaron Griffin
-
Allan McRae
-
Dan McGee
-
Jeff
-
Loui Chang
-
Sebastian Nowicki
-
Thomas Bächler