proposal to remove static libs from -devel packages for FC5

[Daniel Veillard]

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.
OpenOffice used to have its own code tree *inside*. The problem is more to
know who use what, and not shipping -static makes it even harder !

> >  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.

> 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. 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
   - make sure the libraries gets into LSB once reaching that state
   - make sure people developping apps know about it and stop copying code
     or compile statically

  Forcing developpers to go though hoops to get where they need, inventing
new process and loosing trackability of those is the wrong way.
  At least if you have a static library shipped, you can guess what application
linked to it based on code analysis, and detect in as much as possible
automatic way how to get them fixed. If developpers start having their in-house
static compilation environment:
    - we loose as a developper platform
    - guessing what uses what statically starts becoming impossible.

  I really think your point of view is detrimental to the platform acceptance
and to the overall manageability, sorry I still disagree with your approach to
the problem (not with the problem !)

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/