* Alan McKinnon <[EMAIL PROTECTED]> wrote:

> A long time ago I read a HUGE thread on b.g.o. about this, the eventual 
> conclusion is that after installation of a lib, a user might well want 
> to link those libs statically and if they are not there, portage will 
> barf big time and has no way to recover or even know what went wrong. 
> Then the poor user sits in mystery wondering which package to remerge 
> to get the .a

Well, if there was an optional useflag (ie. "staticlib") which is 
turned on by default (or maybe "nostaticlib"), I don't see any
problem. Most people will leave them enabled, only who are sure
about this will disable them.

BTW: this leads me to another issue, which goes aroud in my mind for 
a longer time: packages should be split off into several "stripes"
in the binary output. Other packages then could depend on single
stripes at different levels. For example: if some package foo requires
libbar, it would only depend on the buildtime stripe(s) for building
(eg. so headers get pulled in), while at runtime it will only depend
on the runtime stripe(s) of "bar". There could also be separate stripes
for certain locales, docs, examples, etc.

Such an approach could be really useful for binary-only targets (which
don't build themselves) and network installations (eg. arch-dependent
and -independent stripes could be installed separately). 

> Ubuntu can get away with this, the user gets what the packager feels 
> like giving them, our users have *much* more freedom.

I don't have much experiences w/ Ubuntu, but AFAIK this is an binary-
distro. Those distros usually split the (binary) output into two 
separate packages, eg. "libfoo" is only the binary library, while 
"libfoo-devel" contains all the buildtime stuff (*.h, *.pc, ...).
While this approach is quite simple, it's not very flexible and does't
allow finer granulation (eg. separating locales, etc), but requires
great care for filing dependencies.

> What's your reasoning for wanting to do this?

a) saving space / skipping unused stuff
b) preventing accidential static linking. 

While working on PHP and IMAP c-client, I discovered a broken 
libc-client.so* installation (turned out that just a symlink was missing).
PHP always tried to build in the static library (since .so wasnt found),
which leads to missing deps (eg. crypt,pam), after I removed the explicit
deps within PHP. The whole issue began with PHP breaking at this point
after I rebuild evrything w/o pam. PHP explicitly links in pam and crypt
for IMAP c-client if it finds them. Obviously an dirty hack around 
libc-client's extremly poor engineering.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
        http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
        http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-user@lists.gentoo.org mailing list

Reply via email to