[pacman-dev] [PATCH] Introduce destarch keyword into makepkg

Roman Kyrylych roman.kyrylych at gmail.com
Thu Jul 3 07:42:04 EDT 2008

2008/7/2 Thomas Bächler <thomas at archlinux.org>:
> Allan McRae schrieb:
>> Just getting an indication of how common this is.  The multilib stuff in
>> [community] all takes the i686 package as the source and just moves the
>> files to the new locations.  Is there some reason that you cannot use that
>> approach.  Wouldn't all packages you are wanting to make a multilib package
>> for have an i686 package floating about.  Also, with that approach you can
>> actually make the package on the target architecture.
> The approach taken in community doesn't work very well, as putting a library
> package into a different path poses problems. Just one example: glibc has
> the path /usr/lib/gconv hardcoded, now we load the 32 bit glibc on a 64 bit
> system and it tries to load the modules from /usr/lib/gconv, all of which
> are 64 bit binaries, thus incompatible. Similar problems exist for alsa-lib,
> pango, gtk and maybe others. In the community/AUR packages, these are worked
> around by environment variables where possible, but in most cases they are
> just being ignored.
> Thus I started to look into rebuilding all packages required on a 32 bit
> system, adjusting the paths correctly and stripping all unnecessary files.
> This is supposed to be a _clean_ and slim 32 bit runtime without a build
> environment. Right now I got enough libraries to make nspluginwrapper (built
> from source!) and flashplugin work.
> My goal for now is to get nspluginwrapper+flash and wine to work on a 64 bit
> archlinux system. Maybe later I want to add all libraries necessary to
> install and run Google Earth.
> This task motivated the destarch=, STRIP_DIRS and rundepends suggestions I
> posted: In my PKGBUILDs, I would then use
> arch=('i686')
> destarch='x86_64'
> makedepends=('glibc' 'foo')
> rundepends=('glibc-32bit' 'foo-32bit')
> to "cross-compile" the packages on my full arch32 system. I hope this
> clarifies my wishes.

Ah, now this {make,run}depends thing makes sense to me.
Though, for more clarity, IMHO it could be nicier for makepkg -s to
install _only_ makedepends,
and if pkgA is both run-time and build-time dependcy, then write it as:
but obviously that's not backwards compatible, and huge amount of
packages would have to be changed,
and many packages would have dependencies duplicated in 2 variables,
so Thomas' proposal of introducing rundepends makes perfect sense and
is the best way here

Roman Kyrylych (Роман Кирилич)

More information about the pacman-dev mailing list