On 2010/12/6 jesse jaara wrote:

Currently, if one wants to make a pkg, lets say, for an app that only has binaries available and only for 32bit archs, then one usually makes a bin32-appname pkg for it. I don't like this and would like to have the bin32 and the non-bin32 pkgs to be just one pkg with the name of the app. But if one makes this kind of a pkg, one must use ugly if [[ "$CARCH" = .... statements are in the PKGBUILD, so I was thinking that could it be possible to implement some new variables in PKGBUILDS like depends32 and optdepends32 and then build32() {} and package32() {}? I dont know how makepkg is written, so I dont know how hard it is to implement these, but in the best case it shouldn't be more than just one or two if-statements in the code, so if arch is x86_64 use the 32 variables if they are present.

Hello, This seems to assume that pacman and makepkg run on systems that are either 32-bit or 64-bit. IMO, your proposal looks very "ad hoc", and would add unnecessary complications to makepkg, with no benefit when dealing with PowerPC, ARM, and other architectures. -- Rémy.

On Mon, Dec 6, 2010 at 8:48 AM, Rémy Oudompheng wrote:

On 2010/12/6 Rémy Oudompheng wrote:

...

This seems to assume that pacman and makepkg run on systems that are either 32-bit or 64-bit. IMO, your proposal looks very "ad hoc", and would add unnecessary complications to makepkg, with no benefit when dealing with PowerPC, ARM, and other architectures.

However, maybe a sensible way to do that would be to allow build() function to be replaced by "build_$arch" functions in the same fashion as with split packages.

i like that idea, though i wonder if that would also entail allowing for all split functions (possibly) needing an $arch. perhaps `_$arch` could be appended to ANY function in PKGBUILD, and makepkg would use where appropriate; perhaps even build them all using chroots/etc. C Anthony