Plan for Today's (20070625) Release Engineering meeting

[Axel Thimm]

On Tue, Jun 26, 2007 at 08:49:50AM -0400, Matthias Clasen wrote:
> On Tue, 2007-06-26 at 10:47 +0200, Axel Thimm wrote:
> > On Tue, Jun 26, 2007 at 12:44:42AM -0400, Matthias Clasen wrote:
> > > On Tue, 2007-06-26 at 03:00 +0200, Axel Thimm wrote:
> > > > 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.
> > > 
> > > As far as "glib, gtk and friends" are concerned, these do not at 
> > > any symbols in a stable branch, and Fedora release stay on a stable
> > > branch, so your snide remarks are uncalled for, as far as these are
> > > concerned.
> > 
> > I'm sorry, but history says otherwise. Symbols have been added to
> > *stable* releases, and many application were breaking when used on a
> > previous *stable* release.
> 
> Care to provide a concrete example of a symbol that has been added in a
> stable series, breaking applications ? I can't think of any. 

http://www.google.com/search?q=g_assert_warning
(2,460 which all seem to discuss the missing symbol in various higher
stack packages)

And according to the changelog you should be aware of that:

2004-09-29  Matthias Clasen  <mclasen at redhat.com>

	    * glib/glib.symbols: Add g_assert_warning.

But I'm not here o blame you for not keeping forward compatibility of
glib and co, it's about taking this fact as granted and planing this
into any security-updates (virtual) repo or similar application. There
just is no forward compatibility in 99% of all libs, because any
change of the ABI, even just adding new symbols requires an soname
change for forward compatibility.

The usual practice is to not bump sonames if the API/ABI remains
backward compatible, that's what you do, it's OK, but it still breaks
forward compatibility. And even if you would now reconsider and keep
the ABI constant during an soname to ensure both-way compatibility,
there are tons of other libs that do the same, glib was just a real
example with a proven pain track in google.

So it remains: A security update intended to not be used with
updates-released will have to be built against the pure release's
environment w/o any updates in the BRs. There is nothing magical rpm
[1] or a yum-plugin can do to alleviate this.

[1] unless rpm would start to record dependencies on symbol level (!)
-- 
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/e217aa59/attachment.sig>