[arch-ports] PKGBUILD and package release thoughts

[Jason Chu]

Alright, here's some discussion about PKGBUILDs and multiple architecture
support.

We already talked about adding an arch= array to PKGBUILDs.  The array
would list all the architectures a PKGBUILD is known to build on.  I don't
think makepkg should stop a package from building on an architecture that
isn't listed, but it should at least display a really annoying message
warning the user that the package probably won't build properly.

The second thing I wanted to talk about is pkgrels.  We have a problem in
that some releases will only affect one architecture and we don't want
people using other architectures to have to download packages that haven't
changed.

My proposal goes something like this:

We continue using the pkgrel variable the same way.  Each time an update
(that isn't a version update) happens to a package, its pkgrel is
increased.

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.

Using this method we can target changes for different architectures all
while keeping a single PKGBUILD.  There are very few changes needed in
makepkg and the other tools to cover all the upgrade cases that I can think
of.

Thoughts?

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060310/c81a3d65/attachment.pgp>