Re: Discuss-gnustep Digest, Vol 2, Issue 12

[Matthias Klose]

Richard Frith-Macdonald <richard@brainstorm.co.uk> writes:

> On Sunday, January 5, 2003, at 07:21  am, Jonathan Gapen wrote:
> >      A shared library system that addressed these deficiencies would
> > eliminate "RPM dependency hell" for the most part.  A new package might
> > require a newer version of libxml2, but you could install that newer
> > version without the need to re-install every other package that
> > depends on
> 
> > libxml2.  Wouldn't that be nice?
> 
> That's how it works now in most package managers isn't it?

"most", but not dpkg and apt-get. I've heard rumors that an apt
version for rpm's exists: rpm-get, which addresses these issues (iff
the rpm dependencies are correct ...)

> 
> You can 'upgrade' in which case the new package replaces the old one,
> and if the dynamic libraries in the new package have a different major
> version number than executables linked to the old one will need to be
> upgraded.
> 
> Or you can 'install' the new package, leaving the old one in place,
> and other packages won't need upgrading.
> 
> 
> Of course, the package manager may not keep records properly and may
> force you to re-install packages unnecessarily ... but that's a fault
> of the package manager rather than the shared libraries.
> 
> 
> My feeling is that unix shared libraries are good for backward
> compatibility,  and flexible.  I don't really argue with slow, perhaps
> implementations could be faster of course, but startup time is
> fundamentally always going to be slower than static linked software.
> 
> 
> The only alternative I know of is the windows dll ... and shared
> libraries are superior in all respects to that option ... what
> alternative model are you thinking of? or are you just saying that
> you'd prefer static linkage in spite of the binary size penalty?
> 
> I realise that the size may not be a big deal for some people, but I
> only have a 64Kbs link, and the download size is *very* significant to
> me.