[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: HEADS UP: I will be merging christos-time_t by the end of the week
On Mon, Jan 05, 2009 at 02:36:46PM -0500, Thor Lancelot Simon wrote:
> On Mon, Jan 05, 2009 at 10:47:34AM +0100, Bernd Ernesti wrote:
> > On Sun, Jan 04, 2009 at 09:13:57PM -0500, Christos Zoulas wrote:
> > [..]
> > > - all (most) the rest of the libraries get bumped
I still want to know what 'most' means here.
> > I hope that the x11 libraries and other third party libraries are excluded
> > in
> > this library bumping.
> As I said about a minute ago:
> | Any failure to bump the major version of a shared library when the version
> | of one of the libraries on which it depends is bumped is a bug.
> > It will be a pain to update them for ever, keeping in mind that you always
> > need to use a different version number then the offical one.
> Yes. This is a huge pain. But put the blame where it is richly deserved:
> the bug in question is a bug in ELF itself.
> If you *don't* bump the major version numbers of the dependent libraries,
> users' programs mysteriously go bang, and there is no way to predict
> whether or not they will do so.
IMHO the x11-links package has to be modified to cope with the new versions,
which differs between the modular xorg and the 'native' xorg one.
e.g. now there is libXaw6.so.6 and libXaw7.so.7
and afterwards there will be libXaw6.so.7 and libXaw7.so.8 only for the
native xorg on NetBSD, but all other systems stay with the old versions.
This looks very wrong.
Why is the libc major version not changed if all other libaries have to
All programs are now linked against libc, so it should be possible to not
bump the other libraries, since it is required to recompile EVERYTHING after
you compiled something against the new libc.
Main Index |
Thread Index |