Re: New libc6 breaks exim?
Petr Cech <email@example.com> writes:
> On Wed, Sep 27, 2000 at 09:45:01AM -0400 , Greg Stark wrote:
> > Petr Cech <firstname.lastname@example.org> writes:
> > > There is missing a depends or conflicts on libc6 to force libdb2 upgrade.
> > > And there are still problems with GLIBC_2.x symbols ...
> > No that's not what he said. You can't fix library incompatibilities with
> > Debian package conflicts or depends since there might be local compiles on the
> > machine or third party applications from other distributions that break.
> Hmm. I wonder how does RH7 deal with this ...
> > You have to change the soname and allow the old libdb2 to be installed _at the
> > same time_. That way applications compiled against the old libdb2 still work.
> hmm. but that will break us even more with every one else ...
You're saying Redhat released version 7 with a beta glibc and a libdb2 that
isn't abi compatible but didn't bump the soname? That's incredible if true!?
If that's true then it's a lost cause, the glibc maintainers have borked
binary compatibility between linux distributions for a long time. That sucks
big time. It's a real shame after everyone spends so much effort getting
random libraries like libjpeg or libssl synchronized between distributions to
have such a critical library screwed up.
> > Otherwise we're not binary compatible with other distributions, or even
> > programs compiled in potato even.
> no one guarantees backward compatibility. Forward would be good. I understand
> that this is a problem, but the solution is ... ?
Of course it guarantees backward compatibility, it's useless if it doesn't
full ABI compatibility. Any program compiled with the soname of libdb2 should
work on any other system that has a library with that soname. If it's not the
case the soname should be changed.
This means anything compiled on potato or Redhat 6.2 or Suse whatever might
not run on Redhat 7 or woody even if you have the right libraries installed.
Hell we got libc5 -> libc6 working better than that. Worse, such programs
won't just give an error, they'll behave wrong or crash. That should *never*
I can't believe after fucking up the glibc 2.1 release so badly that they're
about to do it again with much less excuse. At least with libc itself you have
major costs associated with bumping the soname, for libdb there's absolutely
no fucking excuse for introducing major binary incompatibility problems like