linking statically against dietlibc: a blocker?

[Ralf Corsepius]

On Wed, 2006-10-04 at 10:45 -0500, Rex Dieter wrote:
> Ralf Corsepius wrote:
> 
> > Static linkage against dietlibc, IMO is nothing but a script-kiddy's
> > attempt to "pimping Linux". There should not be any room for such
> > undertakings.
> 
> Extend that logic a little, and we shouldn't allow dietlibc in Extras at
> all.
Yes, but it might surprise you, the more I think about it, the more Iam
not uncertain about this, because this problem actually consists of
several pretty far fetching issues:

1. "circumventing glibc-calls by syscall-wrappers"

2. "static linkage"

AFAIK, dietlibc does 1) by applying 2), several application do the same
by using local files.

Though I consider both ways to be "pretty stupid", one will always find
people trying to outsmart themselves this way for various reasons
(speed, size, security, portability). Here, having a central library
(such as dietlibc) would still be preferable instead of these people
starting to ship local copies of individual libc-functions.


This consideration however leads to a 3rd issue:
To bring this into a maintainable form, we would have to find a way to
denote dependencies on specific versions of static libs into individual
rpms, which can be applied to check for version updates of static libs
rsp. are supposed to break upon updates of static libs.

(At minimum something like: BR: dietlibc-static = version-release, 
or even more radically, require all static libraries to provide a
virtual provide a libxxxx_a(..) =  version-release, which all packages
using this static lib must Require:)

> Either dietlibc OK for Extras and for Extras pkgs to link-against/use it, or
> not.
I am in favor of changing the GuileLines to require *-static (which
would require dietlibc to be renamed) and to require someones explicit
permission on any case of static linkage.

>   ATM, I'm personally leaning toward the former, especially in cases
> where upstream and the packager/maintainer prefer using dietlibc.

As I wrote before, in most cases, a decision on trade-offs and a balance
between "pimping" and "maintainability" has to be found. Some
packagers/maintainers apparently are "keen on pimping Linux at any
price" - I am not willing to be playing it nice to them.

In addition to all this, another issue has popped up, which IMO renders
shipping static libs as part of Fedora very questionable (to say the
least)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209316


Ralf