| 1 |
Hello again, |
| 2 |
|
| 3 |
|
| 4 |
Over a year or two ago, it was communicated that it supposedly a policy |
| 5 |
that USE=static should only control if a package installs static |
| 6 |
libraries INSTEAD of shared libraries, and never to be used to control |
| 7 |
if static libraries are installed in _addition_ to shared ones or not. |
| 8 |
|
| 9 |
Packages were coerced to stop using USE=static for controlling that, and |
| 10 |
most of them ended up unconditionally installing both static and shared |
| 11 |
libraries. What's worse - they were told that if a package can provide |
| 12 |
both shared libraries and static libraries at once, it just MUST (or |
| 13 |
SHOULD) install them both instead of choosing to not ship the static |
| 14 |
libraries. |
| 15 |
End result that affects me: GNOME does not fit on LiveCD installation |
| 16 |
media anymore. |
| 17 |
|
| 18 |
|
| 19 |
So I'm proposing a USE=static-libs or similar to get out of this |
| 20 |
problem, and a lifting of the supposed (I wasn't around as a dev that |
| 21 |
long ago to know for sure) policy of having to install both instead of |
| 22 |
choosing to never install static libraries. |
| 23 |
|
| 24 |
I am quite sure that absolutely nothing whatsoever uses about 97% of the |
| 25 |
static GNOME libraries we are now installing as an end result. How can I |
| 26 |
be sure? Because everything worked just fine when static libraries |
| 27 |
weren't installed in the past thanks to that not happening from |
| 28 |
USE=static missing on most systems for years, and you'd have to be quite |
| 29 |
crazy if you required static version of desktop libraries with well |
| 30 |
established and followed ABI guarantees. |
| 31 |
|
| 32 |
Those that aren't absolutely sure that there is no use case for static |
| 33 |
libraries, could then use a USE=static-libs or similar to not |
| 34 |
unnecessarily install static libraries that are not going to ever be |
| 35 |
used. And LiveCD media could avoid all these static libraries, that it |
| 36 |
currently has to ship just because the packages by default install that |
| 37 |
cruft for no real technical reason (and it has to follow that due to |
| 38 |
GRPs). |
| 39 |
I would use USE=static-libs on packages like gtkmm, that have good |
| 40 |
reasons to provide a static version - it allows Gentoo users that would |
| 41 |
like to do commercial or universal C++ based development against Gentoo |
| 42 |
system packages, as it avoids feared libstdc++ ABI breaks (there's even |
| 43 |
a request for it in bugzilla). |
| 44 |
|
| 45 |
|
| 46 |
|
| 47 |
There are packages in the tree that are required to install static |
| 48 |
libraries, or something else in the system breaks. So INSTALL_MASK=*.a |
| 49 |
is not a solution in my eyes. |
| 50 |
|
| 51 |
|
| 52 |
Useful comments, thoughts, agreements? |
| 53 |
|
| 54 |
|
| 55 |
|
| 56 |
I have had some additional ideas for handling static libraries better at |
| 57 |
a package manager level, but those still need to be fleshed out and put |
| 58 |
into writing. |
| 59 |
Things like possibility to rebuild all packages that link to a static |
| 60 |
library that was now upgraded, so the higher level package could use a |
| 61 |
relinking to benefit from the bug fixes from the new library; optional |
| 62 |
ability to install only the type of library currently needed - shared or |
| 63 |
static, etc. Much of it goes to blue-sky ideas though with minimal |
| 64 |
benefit for normal desktop/server systems and potentially high |
| 65 |
maintenance effort, so I haven't put much effort into putting it into |
| 66 |
writing. But maybe someone interested wants to chat on IRC on the topic. |
| 67 |
|
| 68 |
|
| 69 |
-- |
| 70 |
Mart Raudsepp |
| 71 |
Gentoo Developer |
| 72 |
Mail: leio@g.o |
| 73 |
Weblog: http://planet.gentoo.org/developers/leio |
Archives