hurd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: time for libio?


From: Thomas Bushnell, BSG
Subject: Re: time for libio?
Date: 29 Nov 2001 17:04:31 -0800
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Roland McGrath <address@hidden> writes:

> > What I'm saying is that this is like any other soname-bumping library
> > upgrade on Debian--it doesn't require a flag day, as long as both the
> > old and new libraries can happily co-exist on the same system.  And,
> > they can, right?
> 
> They can be made to, yes (what part of "doable" did you not understand?).
> It's easier if they don't have to.  The biggest part of it being easier is
> not having to worry about whether you got it right in all the details.
> Getting it right is straightforward enough in each detail; but you need to
> be sure you're considering all of them carefully when you should be, which
> is incompatible with maximal laziness.

Ok, bear with me as I try to figure this out.

The different library versions install different .so's, right?  I
mean, this is how it works for people compiling from source.  (Ignore
Debian and packaging for a minute.)  There are just multiple .so's,
each with its own soname, and things Just Work.

We do have the "library dependency soname problem": in principle we
have to bump the soname on every library that includes a dependency on
libc, when the libc soname bumps.  (If you recall, we more or less
discovered this problem by accident once, and never really came to a
good solution.)  Solving this problem is not easy at present, and may
well be hard enough that we should punt the attempt and go to a flag
day.  

(The library dependency soname problem doesn't come up much in Debian
because it only happens when a depended-on library has an soname bump,
and that's only really common for libc.)

> The word from Marcus was that all this "life will be fine when you bump a
> soname" from Debian was a load of crap in practice, i.e. requiring explicit
> manual cooperation from every Debian package maintainer or something like
> that.  If that's really where it's at, then there is no point at doing
> things really right on a finer granularity anyway.

I think the problem is that once a library maintainer were to put a
new version of the library up, and then a package gets installed that
depends on the new version, every user--and build agent--gets the new
library, and like a snowball, pretty much every package starts needing
to be rebuilt.  But things work ok for users along the way--it's just
that it's very hard to go back.

Thomas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]