On Sat, Mar 11, 2006 at 12:05:06AM +0100, Andreas Radke wrote:
Jason Chu schrieb:
We also add support to makepkg for a couple more variables. Let's call them pkgrel_i686, pkgrel_amd64, etc. If one of these variables exists, makepkg (and gensync, and updatesync...) will us that pkgrel for the architecture, instead of the pkgrel.
What this lets us do is something like this:
Package foo is at version 1.2.3-1. A change that only affects i686 happens, so the package maintainer makes the changes (marking them with [ "$CARCH" = "i686" ] && ), updates the pkgrel to 2, and sets pkgrel_i686=2 and leaves all the other variables (pkgrel_amd64, etc) set to 1.
When you build the package on i686, it comes out as 1.2.3-2. If you build it on any of the other listed architectures, it comes out as 1.2.3-1.
This does mean that if there's a release for all architectures, it becomes -3 everywhere and amd64 users see a jump from -1 to -3. We already have a similar situation with the testing repo.
Do we really need more variables? Why not leave only one pkgrel number e.g. foo 1.0-1. If the x86_64 bit package needs a fix we would build only a 1.0-2 on x86_64 and let out not affected architectures. Next common release would be 1.0-3 for all archs.
Is it possible that way?
And maybe you should start in another mail the svn/cvs war again ;-)
AndyRTR
My problem with that is that you really depend on your version control to give you the right versions for each architecture and keeping them in sync becomes difficult again. It's possible, but with the more-variables method you could take either PKGBUILD and get the same output on amd64. With yours, I'd get this amd64 -2 version that never actually existed. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.