Plan for Today's (20070625) Release Engineering meeting

Axel Thimm Axel.Thimm at ATrpms.net
Tue Jun 26 01:00:45 UTC 2007


On Mon, Jun 25, 2007 at 08:36:00PM -0400, Jesse Keating wrote:
> On Monday 25 June 2007 20:31:51 Axel Thimm wrote:
> > If for example glibc has been updated yum update foo will not pull it
> > in. Try it.
> 
> If it has been updated and the new update of foo will not run
> without the newer glibc and there are no rpm requirements on said
> newer glibc libraries, we've got much bigger issues.

True, but that's everyday's packaging business and is called "lack of
forward compatibiliy in libraries". Actually that was the reason for
having to build against only securty updates onstead of the whole
update repo given in the trimmed away quote of mine.

Now to get to real example: Replace glibc with glib/gtk and friends,
that keep the same soname since Moses' birth and add symbols on the
row. You can build something on F7's glib and from a packaging POV it
will still fit into FC5 or FC4, but when the app runs it will break
with missing g* calls.

Unfortunately someone set up the myth ages ago that adding new symbols
to a library is not reason enough to change to soname, since backwards
compatibility is retained. But the problem here is forward
compatibility which is broken, and almost every library follows this
scheme, there is none to very few that are forward-compatible.

So broken forward compatibility in libraries is "normal" and an
application built on the same soname in the future and being brought
back to the past will be missing symbols. And that's exactly the
security-updates model with building security updates against the
whole released-updates use case.

So you are really only left with the three alternatives I wrote in a
previous mail in this thread.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070626/6db9a2ec/attachment.sig>


More information about the Fedora-maintainers mailing list