Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)

Kevin Kofler kevin.kofler at chello.at
Fri Mar 12 15:07:42 UTC 2010


Terry Barnaby wrote:
> I really strongly disagree that ABI interfaces of the mainly used
> shared libraries could be allowed to change in a "stable" release.
> We develop internal applications that are packaged and go out to a few
> users. We use Fedora primarily as an OS to run applications we need
> rather than an experimentation platform.

Then you as the provider of those applications are responsible for 
rebuilding them.

> I consider it unacceptable for a system "update" to break the
> ABI for these and any other third-party packages. It would mean failures
> in the field that would require live intervention. This is what
> rawhide is for.
> We would end up by turning off Fedora updating on these systems and in
> effect manage the updates of the system ourselves probably from our own
> repository (our own Fedora spin) or, probably move to a different system.
> I am sure a lot of users, like us, use Fedora for there own purposes and
> develop there own applications for it, but do not maintain them in the
> main Fedora package tree. There's more to Fedora than just the main Fedora
> repository...

Why are you using the conditional tense? Fedora CURRENTLY does NOT provide 
any ABI guarantees. There ARE ALREADY updates which change the ABI (you 
recognize them as they are normally grouped with rebuilds of other stuff for 
the bumped ABI). The people who want to change things are the ones who DON'T 
want to allow soname bumps. The only reason the core libraries you use are 
apparently not affected is that those libraries are used by so many packages 
that rebuilding them all would be impractical.

That said, this also leads to a possible solution: we could make a short 
list of "core" libraries for which soname bumps would be impractical to 
perform in a release, which would then also double as some form of ABI 
guarantee.

        Kevin Kofler



More information about the devel mailing list