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
Attachment:
pgp6nDKHuvz8s.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
