Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

Am Tue, 10 Nov 2009 08:49:16 +0100
schrieb Remko van der Vossen <wich AT yuugen.jp>: 

> How about having glibc be just x86/x86_64 and moving support for any
> other platforms to a separate spell, e.g. glibc-compat. If we do it that
> way it's no problem if the version of glibc-compat lags a bit behind
> glibc.

Untangled spells would indeed be nice. So, we are speaking of spells like:

glibc-x86
glibc-alpha
glibc-arm
glibc-x86-cvs

and even others like

eglibc
dietlibc
uclibc

... all providing LIBC? Or, rather, since I don't know how well it would work 
to have providers that depend on your selected build architecture, some logic 
in basesystem's DEPENDS to select the proper libc?
We do have the fortunate case that we do not have a lot of direct depends on 
libc in spells.

Thinking a bit more... having one glibc for each arch would also be bloat, 
actually it's about

glibc: The glibc package for architectures supported by vanilla upstream.
glibc-ports: The glibc package for architectures requiring glibc-ports, 
possibly plus more patches.

... and the joker of supporting different choices for the system libc (other 
than GNU libc).

That would be fine by me, only question is what is the proper mechanism to 
select the right spell? Also, I am wondering a bit about a good transition 
mode for ported archs (well, my one Alpha box;-) We cannot make glibc-ports 
just conflict with glibc, as the build needs the old glibc installed. We'd 
need to do the PRE_INSTALL stuff of saving the old lib before dispelling... 
of course that's fragile...


Alrighty then,

Thomas.

Attachment: signature.asc
Description: PGP signature