[arch-multilib] Addition of jack2-multilib and multilib push perms

Thomas Bächler thomas at archlinux.org
Wed Dec 7 09:37:09 EST 2011


Am 07.12.2011 15:08, schrieb Ray Rashif:
> On 7 December 2011 17:13, Thomas Bächler <thomas at archlinux.org> wrote:
>> I still don't understand why you can't just build a lib32 package that
>> doesn't conflict with the usual jack/jack2 package.
> 
> Sorry, I should've made that clear from the beginning. It is possible,
> but it is (a) non-trivial and (b) a hassle to maintain. There is no
> way to build out a 32-bit library without patching your way through
> the buildsystem [1] _and_ patching the existing pure 32-bit and 64-bit
> 'jack2' package to make way for a -lib32 one [2] (credits go to user
> 'speps' for demonstrating this).
> 
> Now, I'm pretty sure you would think that's a PITA, as I had thought,
> deciding on a replacement package instead (yes, a lib32 package was
> the obvious initial idea). The users also told me they would prefer a
> lib32 package, so it's not like I ignored that. Basically, upstream
> here gives you the necessary method to keep a hybrid build of their
> software, but does not modularise the process thinking they'd save us
> distributors the trouble.

Fair enough. I agree this is easier, and the explanation justifies the
method.

Still another idea to think about: What about going through the whole
build process including --mixed, but then only packaging the 32 bit
libraries? Will that work as well?

>> Also, there is no provides on jack2, why?
> 
> As you can see, the second of the splits has this provision, so that's
> probably an accident from the last edit I made on the PKGBUILD.

Okay.

>> But the most important thing: There is no makedepend on gcc-multilib or
>> any other of the multilib build tools. How could this build a 32 bit binary?
> 
> There is no need to makedepend on 'gcc-multilib' as it should already
> be there in a multilib system, sort of analogous to the 'base-devel'
> group for normal systems. I had 'gcc-libs-multilib' initially (due to
> namcap's report), but upon noticing that a chroot build only requires
> 'lib32-glibc', and after a user tested the package to be working for
> his hybrid purpose, I removed the unnecessary dependency. The 32-bit
> library is there at the end of the day:

If you build in a clean chroot using devtools, it will (IIRC) install
the base multilib devel packages.

However, if a user were to build inside the normal system, we would only
assume base-devel to be present! Even if you have multilib packages
installed, you can have a system without multilib devel packages (as
mine - I have lib32-glibc, lib32-gcc-libs and so on, but no
gcc-multilib, no binutils-multilib, no libtool-multilib and no
gcc-libs-multilib!). We have gcc-multilib as a makedepend everywhere as
far as I can see, so please add it here as well.

> Let me know if there's anything else that needs to be done to make
> this compatible with [multilib].

Alright. I'll wait until later tonight (now + 5 hours), and if nobody
objects until then, I'll give you permissions to multilib (you can
already check into svn-community, all you need is the right to write to
the multilib ftp directory).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-multilib/attachments/20111207/dce05770/attachment-0001.asc>


More information about the arch-multilib mailing list