proposal to remove static libs from -devel packages for FC5

[Ralf Corsepius]

On Thu, 2005-07-28 at 10:14 -0400, Daniel Veillard wrote:
> On Thu, Jul 28, 2005 at 03:53:40PM +0200, Ralf Corsepius wrote:
> > On Thu, 2005-07-28 at 09:20 -0400, Daniel Veillard wrote:
> > >   I don't think there is any in the distro (I think open-office specific
> > > version was removed).
> > You think ... this isn't enough. You should be sure, otherwise in case
> > of serious emergency with libxml, _you_ can't react.
> 
> Well if you think not shipping a static lib will help, you're on crack sorry.
Thanks for this "warm" welcome ;)

> OpenOffice used to have its own code tree *inside*.
That's a completely different problem.

>  and not shipping -static makes it even harder !
I am not talking about "banishing static libs", I am talking about
moving static libs from "*-devel" packages into "*-static" packages to
raise the threshold for users/applications wanting to link against them.

> > >  The problem of course is for ISV and independant 
> > > developpers. Sorry you tried to attack the problem from the wrong angle.
> > Why, what's technically wrong with my proposal? What would you propose
> > instead?
> > 
> > Shipping static libraries to me means handing people a loaded gun.
> > It's only a matter of time until somebody stumbles and shoots himself.
> 
>   We can stop shipping any compiler too, sounds the way to go.
With all due respect, ...

> > I am worried about all statically applications nobody exactly knows what
> > they actually are linked against, and therefore are hot candidates to be
> > missed during security updates.
> 
>   The point is to educate upstream, not make the life of users miserable.
> It's like playing "we have a firewall so we are safe" game, it's wrong,
> static libs may be required, linking statically to libxml2 *Right Now* is
> a requirement for an ISV wanting to ship an LSB compliant application using
> libxml2.
Where from the LSB do you conclude the LSB is disallowing dependencies
on shared libs? I don't see any such requirement.

>  The best way to avoid what you are afraid of are:
>    - make sure our set of libraries is API and ABI stable, including for
>      C++ user
LSB-compliant, C++ and ABI ... see
http://gcc.gnu.org/ml/gcc/2004-07/threads.html

>   I really think your point of view is detrimental to the platform acceptance
> and to the overall manageability,
I don't see this, conversely, such a change would be transparent to the
majority of users/developers, because "BR: *-devel" would remain
functional as before for those packages providing shared libs.

Only those packages which explicitly try to link statically would be
affected.

Ralf