[crux64] multilib vs. soft dependencies

Lucas Hazel lucas at die.net.au
Wed Jun 25 13:18:26 UTC 2008


On Wed, 25 Jun 2008 08:15:20 +0200
Johannes Winkelmann <jw at smts.ch> wrote:

> Hi Lucas,
> 
> On Wed, Jun 25, 2008 at 11:09:31 +1000, Lucas Hazel wrote:
> > 
> > Some configure scripts automatically detect the presence of
> > libraries, on a single library system this isn't a problem.
> > However, when building 32bit support libraries on a mixed 32/64bit
> > system the 64bit libraries get detected, but not tested by the
> > configure script, only to fail during the linking process.

> Interesting problem. From your script it seems that if the compat port
> of that soft dependency is installed, it will work again, did I read
> that correctly?

That's correct. You either remove the 64bit port, build it, reinstall
the 64bit port or install the compat32 port and build again.

> Would it be a pkg-config problem then, or how is the wrong library
> detected by configure?

If only everyone used pkg-config, things would be a lot easier. In
pkgmk.conf I just set PKG_CONFIG and PKGCONFIG (make up your mind
dammit!) to /usr/bin/pkg-config32, which solves a lot of the auto
detection problems (pkg-config --exists). However there are still a
collection of ports that ship with their own *-config script. This is
where the problems exist.

Initially *_CONFIG=/usr/bin/*-config needs to be set in pkgmk.conf (a
pkgmk.conf.d would be nice ;) ), however I found that some will fall
back to just detecting the presence of headers and the problem is back
again.

That said, I've only come across 2 ports that need the
compat32_dep_check hack (but there may be a better solution),
gtk-compat32 and libxslt-compat32.

> I'd like to look at one of these to get a better idea, is cups a good
> example?

I have the ports available on http://git.die.net.au/cgit

compat32 and multilib ports are available for core, opt and xorg. I'd
like to see how mine are different from the pure64 alternative, as I
suspect that other than a few core ports, not much will be different.

If you want to clone core for example it's

git://git.die.net.au/crux/ports/core

> > It is not feasible to add all soft deps to the compat32 Pkgfile so
> > these need to be detected. Rather than let these fail and let the
> > user figure it out, I've come up with a solution, but I'm not sure
> > how it would bode with with CRUX philosophy.
> Would it also be possible to disable the soft dependencies
> explicitely? I think you mentioned something like this for libxslt.
> Or the other way around, adding the compat32 ports as hard
> dependencies.
> 
> Both are just workarounds, though, but depending on the number of
> ports we'll end up with in compat32 could also be feasible.
> 
> 
> > As I said, I'm not sure if this sits will with the CRUX way of doing
> > things, such as enforcing dependencies. But it's a necessary evil to
> > get compat32 ports to compile cleanly. That or we can let the end
> > user figure out the soft deps on their own.
> One thing I'm not sure yet is how many compat port we will end up in
> the long run, i.e. whether it's okay to cover to typical use cases, or
> whether we need more and more over time since users want more ports.

I'm up to 64 compat32 ports, which was about how many I had before I
started the new repos. The bulk of this is xorg and gtk stuff, which
should be enough get get a lot of popular 32bit binary programs to
work (flash, acroread, wine). There may be a few more compat32 ports
needed, but I belived most of the groundwork has been laid here.

> If the compat ports are an small set, then I think it could be okay to
> add a special solution, especially since I still hope that at some
> point in time we'll be able to drop the compat ports altogether,
> although that may take some years... I'll have to think a bit longer
> about the way you implemented it (lack of coffee and such).

There's probably a better solution, but as the saying goes, a bad
solution is better than no solution at all. If the number of cases that
have soft deps turns out to be quite small it would be quite feasible
to simply write it into the Pkgfile for each case.

> The one thing I'd like to avoid is that the method as is is picked up
> by other packagers to run random scripts in Pkgfiles, because they
> see it in our ports (you know, like running pre-install from there).

^^ I just wrote the drop in script because I had a fear that I would end
up writing the same few lines over and over, which in the end turned
out to be for only 2 cases. Hopefully there'll be a way to get around
it, but for now it's working.

> > I'm not sure how interested the rest of you are in multilib, but I'm
> > not really interested in using a 64bit only system on my home
> > desktop. I need to watch youtube videos and I need to be able to
> > play GTA when the world is getting me down :)
> Heh. I'm pretty sure that the majority of our users today will have
> some 32-bit applications they want to run, so at this point multilib
> seems favourable to me. As mentioned I hope that we can go pure 64 at
> some point in time, but I don't see that happening anytime soon.

Well, I for one will be sticking with multilib regardless of which way
the official version decides to go. Granted many mainstream programs
will go 64bit in the end (I hear that flash10 will have 64bit linux
support), redhad is working on an opensource java plugin, etc),
unfortunately I don't think 32bit is going anyware for a long time.

-- 
Lucas Hazel <lucas at die.net.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.crux.nu/pipermail/crux64/attachments/20080625/8c16bcb9/attachment.asc>


More information about the crux64 mailing list