| 1 |
* Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
| 2 |
|
| 3 |
> A long time ago I read a HUGE thread on b.g.o. about this, the eventual |
| 4 |
> conclusion is that after installation of a lib, a user might well want |
| 5 |
> to link those libs statically and if they are not there, portage will |
| 6 |
> barf big time and has no way to recover or even know what went wrong. |
| 7 |
> Then the poor user sits in mystery wondering which package to remerge |
| 8 |
> to get the .a |
| 9 |
|
| 10 |
Well, if there was an optional useflag (ie. "staticlib") which is |
| 11 |
turned on by default (or maybe "nostaticlib"), I don't see any |
| 12 |
problem. Most people will leave them enabled, only who are sure |
| 13 |
about this will disable them. |
| 14 |
|
| 15 |
BTW: this leads me to another issue, which goes aroud in my mind for |
| 16 |
a longer time: packages should be split off into several "stripes" |
| 17 |
in the binary output. Other packages then could depend on single |
| 18 |
stripes at different levels. For example: if some package foo requires |
| 19 |
libbar, it would only depend on the buildtime stripe(s) for building |
| 20 |
(eg. so headers get pulled in), while at runtime it will only depend |
| 21 |
on the runtime stripe(s) of "bar". There could also be separate stripes |
| 22 |
for certain locales, docs, examples, etc. |
| 23 |
|
| 24 |
Such an approach could be really useful for binary-only targets (which |
| 25 |
don't build themselves) and network installations (eg. arch-dependent |
| 26 |
and -independent stripes could be installed separately). |
| 27 |
|
| 28 |
> Ubuntu can get away with this, the user gets what the packager feels |
| 29 |
> like giving them, our users have *much* more freedom. |
| 30 |
|
| 31 |
I don't have much experiences w/ Ubuntu, but AFAIK this is an binary- |
| 32 |
distro. Those distros usually split the (binary) output into two |
| 33 |
separate packages, eg. "libfoo" is only the binary library, while |
| 34 |
"libfoo-devel" contains all the buildtime stuff (*.h, *.pc, ...). |
| 35 |
While this approach is quite simple, it's not very flexible and does't |
| 36 |
allow finer granulation (eg. separating locales, etc), but requires |
| 37 |
great care for filing dependencies. |
| 38 |
|
| 39 |
> What's your reasoning for wanting to do this? |
| 40 |
|
| 41 |
a) saving space / skipping unused stuff |
| 42 |
b) preventing accidential static linking. |
| 43 |
|
| 44 |
While working on PHP and IMAP c-client, I discovered a broken |
| 45 |
libc-client.so* installation (turned out that just a symlink was missing). |
| 46 |
PHP always tried to build in the static library (since .so wasnt found), |
| 47 |
which leads to missing deps (eg. crypt,pam), after I removed the explicit |
| 48 |
deps within PHP. The whole issue began with PHP breaking at this point |
| 49 |
after I rebuild evrything w/o pam. PHP explicitly links in pam and crypt |
| 50 |
for IMAP c-client if it finds them. Obviously an dirty hack around |
| 51 |
libc-client's extremly poor engineering. |
| 52 |
|
| 53 |
|
| 54 |
cu |
| 55 |
-- |
| 56 |
--------------------------------------------------------------------- |
| 57 |
Enrico Weigelt == metux IT service - http://www.metux.de/ |
| 58 |
--------------------------------------------------------------------- |
| 59 |
Please visit the OpenSource QM Taskforce: |
| 60 |
http://wiki.metux.de/public/OpenSource_QM_Taskforce |
| 61 |
Patches / Fixes for a lot dozens of packages in dozens of versions: |
| 62 |
http://patches.metux.de/ |
| 63 |
--------------------------------------------------------------------- |
| 64 |
-- |
| 65 |
gentoo-user@l.g.o mailing list |
Archives