I think Xentac's suggestion is simple enough..but do we really need to have the original "pkgrel" variable when we have the new pkgrel_i686 and pkgrel_amd64? What purpose does the original "pkgrel" variable serve when the final package release number does not depend on it? ganja_guru Jason Chu wrote:
All your questions should be answered here:
http://www.archlinux.org/pipermail/arch-ports/2006-February/000112.html
Both the build() and any source=() changes can happen with [ ] style testing. This is bash after all ;)
Jason
On Fri, Mar 10, 2006 at 04:46:28PM -0800, eliott@cactuswax.net wrote:
I appreciate the goal of joining multiple architectures into a single pkgbuild, but I haven't heard much (at least that I remember) lately about how pkgbuilds with different build requirements based on architecture are going to be handled.
Are there going to be seperate "build" definitions, based upon architecture? i686_build() ppc_build()
or is there going to be some type of variable testing inside a single build defintion... build() { if [ $ARCHx = "i696x" ]; then <custom stuff here> fi }
Also, would there be seperate file sections? If one architecture requires a patch that another one doesn't, are all files fetched for build regardless?
I suppose I am saying that a little more background into how the overall structure is going to work, may help make informed opinions about versioning conventions.
I apologize if I missed the discussion of the above, and this has already been covered.