Request for review: glpk -AND- shared vs static libs in Extras

[Ralf Corsepius]

On Tue, 2005-07-26 at 09:31 -0500, Quentin Spencer wrote:
> Ed Hill wrote:
> 
> >On Tue, 2005-07-26 at 08:40 -0500, Quentin Spencer wrote:

> >>One note about this package. The upstream sources do not provide for 
> >>building shared libraries. T

> I think you're right about saving disk space being less critical in 
> Extras than in core, but I also think that in general it's good to save 
> space where possible.
Sorry, you are missing the point. 

Space is only minor concern, here. The actual issue is maintainability
(bug fixing, upgrades) of applications having been linked against static
libs.

While for dynamically linked applications, replacing the shared lib
underneath fixes bugs inside of the library for all applications at
once, you'd have to recompile all applications which had been statically
linked against a library.

What makes this situation worse: An application's dependency on a static
library is not visible at the rpm level. Dynamically linked applications
are visible.

I guess, you might not be familiar with the zlib (libz.a) disaster
having happened a couple of years ago. 

In a nutshell: Several years ago, a serious vulnerability had been found
in libz. Unfortunately, many (most) applications had been statically
linked against vulnerable libz.a's. Worse, some applications had been
linked against vulnerable versions of libz.a having been shipped as part
of the application's sources. At this point, distributors, vendors and
developers all around the world were facing the problem of identifying
potentially vulnerable packages, applications and libraries.

At this point, they understood why static linkage and (worse)
package-local copies of common libs are harmful.

FWIW: IMO, it doesn't need to be a prophet to expect sqlite to be one
hot candidate for a similar disaster in near future :(

Ralf