Thomas Bächler wrote:

This patch introduces a new STRIP_DIRS makepkg.conf option to change makepkg's search path when stripping binaries.

Again, I am happy for this to be included once documentation has been added (makepkg.conf.5.txt). Allan

On Tue, Jul 01, 2008 at 01:11:11PM -0500, Dan McGee wrote:

I've been contemplating something like this for a while as well. What do others on the list think, is this getting to be too much, or does this make sense? I think I would be fine with it. We will need documentation (namely PKGBUILD.5.txt) to be patched as well in the final patch.

http://bugs.archlinux.org/task/2891 Aaron closed this as "Wont't implement" two years ago.

On Tue, Jul 1, 2008 at 2:32 PM, Thomas Bächler wrote:

Miklos Vajna schrieb:

...

...

I've been contemplating something like this for a while as well. What do others on the list think, is this getting to be too much, or does this make sense? I think I would be fine with it. We will need documentation (namely PKGBUILD.5.txt) to be patched as well in the final patch.

Didn't think of that.

...

http://bugs.archlinux.org/task/2891

Aaron closed this as "Wont't implement" two years ago.

My name isn't Aaron, now is it?

It is a good feature for a packager. I am doing some packages where I always have to build with -d, as some of the dependencies are never present at build time. However, I still want makepkg to check whether all other dependencies are there.

I do see the use in this because I build regularly where I need to use the -d option, which unfortunately prevents a single dependency from being checked. Two years is a long time, so there has been plenty of time to reconsider, and I find the reasons in the bug report just as valid as they were two years ago. -Dan

Dan McGee wrote:

I do see the use in this because I build regularly where I need to use the -d option, which unfortunately prevents a single dependency from being checked. Two years is a long time, so there has been plenty of time to reconsider, and I find the reasons in the bug report just as valid as they were two years ago.

I like the idea as I frequently use -d for x86_64 rebuilds and this would make it easier to build in a clean chroot. Allan

Thomas Bächler wrote:

When a package A requires a package B at runtime, but B is not needed for building A or B cannot be installed while A is being built, rundepends=('B') can be used to add B to A's dependencies, omitting the dependency check at built time.

Any chance of resubmitting this with the required documentation added (PKGBUILD.5.txt and addition to PKGBUILD.proto)? I think that this patch can be included once that is done. Allan

Dan McGee wrote:

On Tue, Jul 15, 2008 at 1:27 AM, Allan McRae wrote:

...

Thomas Bächler wrote:

...

When a package A requires a package B at runtime, but B is not needed for building A or B cannot be installed while A is being built, rundepends=('B') can be used to add B to A's dependencies, omitting the dependency check at built time.

Any chance of resubmitting this with the required documentation added (PKGBUILD.5.txt and addition to PKGBUILD.proto)? I think that this patch can be included once that is done.

Hello old thread! Anyone still interested in this? I'm not sure what the status on it is, other than it is probably my fault it got dropped on the floor.

The patch was never resubmitted and it is way down the priority list for me so I had forgotten all about it to. Anyway, I will be writing documentation for the package splitting stuff in makepkg soon so I could include that if no-one else does. I would prefer someone else did it... Allan

Teran McKinney wrote:

Hey,

This is already in Icadyptes' makepkg as runtimedeps=(). Not sure if runtimedeps=() matches the PKGBUILD variable naming scheme as much, but I would appreciate considering to use runtimedeps=() instead. Although if you go with rundepends=(), I'll probably switch over too.

Glad that there is some interest for this in the mainline makepkg.

Thanks, Teran

This is just my opinion... but if you do not submit a patch with the changes you are using in Icadyptes, then I really don't care what you are doing. You have previously been encouraged to submit the changes you made for consideration and I have yet to see a single patch. Allan

On Thu, Apr 16, 2009 at 7:19 AM, Teran McKinney wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Hey,

This is already in Icadyptes' makepkg as runtimedeps=(). Not sure if runtimedeps=() matches the PKGBUILD variable naming scheme as much, but I would appreciate considering to use runtimedeps=() instead. Although if you go with rundepends=(), I'll probably switch over too.

That seems inconsistent as we already have: DEPENDS makeDEPENDS optDEPENDS and now you want runtimeDEPS instead of runtimeDEPENDS or runDEPENDS?

On Tue, Jul 1, 2008 at 8:58 PM, Allan McRae wrote:

Thomas Bächler wrote:

...

If destarch is added to a PKGBUILD,

I read that as de-starch and was confused for a while... :)

...

makepkg sets the architecture of the resulting package to $destarch instead of $CARCH. This is useful if you want to cross-create packages for one architecture on the other.

Using

arch=('i686') destarch='x86_64'

makes it possible to build multilib packages and to build grub without the export CARCH="x86_64" hack.

So when you are building the i686 packages, you have to comment out the destarch value? I think it would be better to use a flag like -D/--dest x86_64.

I wanted to make this same point too but I was afraid I interpreted the patch wrong. It doesn't seem intuitive to have to comment things in and out of the PKGBUILD. Of course, it is now just as easy to do: CARCH=blah makepkg which seems to make this patch not worth it? -Dan

On Tue, Jul 1, 2008 at 11:11 PM, Allan McRae wrote:

Dan McGee wrote:

...

On Tue, Jul 1, 2008 at 8:58 PM, Allan McRae wrote:

...

Thomas Bächler wrote:

...

If destarch is added to a PKGBUILD,

I read that as de-starch and was confused for a while... :)

...

makepkg sets the architecture of the resulting package to $destarch instead of $CARCH. This is useful if you want to cross-create packages for one architecture on the other.

Using

arch=('i686') destarch='x86_64'

makes it possible to build multilib packages and to build grub without the export CARCH="x86_64" hack.

So when you are building the i686 packages, you have to comment out the destarch value? I think it would be better to use a flag like -D/--dest x86_64.

I wanted to make this same point too but I was afraid I interpreted the patch wrong. It doesn't seem intuitive to have to comment things in and out of the PKGBUILD.

Of course, it is now just as easy to do: CARCH=blah makepkg

which seems to make this patch not worth it?

But CARCH=blah requires that blah is in the arch array which indicates that is can be built on that arch - not the case for grub.

Oooohh, I guess I still didn't understand this then. So what is the deal here? We are just faking the arch extension at the end along with putting a different value in PKGINFO? I guess someone explaining the entire situation for stupid me would be best- I'm not very familiar on the grub build procedure, especially when it comes to building for "other" architectures.

Would this make more sense? arch=('i686' 'x86_64) buildarch=('i686')

To build for i686 just type "makepkg" on an i686 machine. To build for x86_64, type "makepkg -D x86_64" on an i686 machine. Typing "makepkg" on a x86_64 machine fails. I think this would be clearer.

I would rather not introduce a new variable for such a specific use case like this. It seems overkill to me, especially since i686/x86_64 is one of the few cases where the architectures share a lot in common. You wouldn't really do something along the lines of i686/ppc for instance. -Dan

Thomas Bächler wrote:

...

Would this make more sense? arch=('i686' 'x86_64) buildarch=('i686')

To build for i686 just type "makepkg" on an i686 machine. To build for x86_64, type "makepkg -D x86_64" on an i686 machine. Typing "makepkg" on a x86_64 machine fails. I think this would be clearer.

Yeah, I just saw that this makes much more sense for grub, as you need the package for both architectures (right now, we actually change a comment everytime we build it). However, my motivation was that right now I am building some multilib stuff and have packages that always have to be built on i686 and installed on x86_64. So at the end of the build() procedure I need to do 'export CARCH="x86_64"', which is a hack that doesn't work with -L for example.

Using a -D option would mean that I have to build 20 or 30 packages with '-D x86_64' all the time. My goal was to make the build procedure for these packages intuitive enough, so you can't build them "wrong".

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. Allan

2008/7/2 Thomas Bächler :

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. <just-thinking> 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: makedepends=('pkgA') depends=('pkgA') 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 </just-thinking> -- Roman Kyrylych (Роман Кирилич)