[CentOS-devel] tracking ABI changes in C/C++ libraries

Tue Jul 20 13:05:49 UTC 2010
Jeff Johnson <n3npq at mac.com>

On Jul 20, 2010, at 8:38 AM, Karanbir Singh wrote:

> Hi,
> On 07/20/2010 10:31 AM, Andrey Ponomarenko wrote:
>> The examples of integration are:
>> http://packages.debian.org/experimental/apt
>> http://rpm5.org/
>> http://linuxtesting.org/upstream-tracker/
> looks good.
>> Now our team is working on the integration of the tools to the OBS
>> (openSUSE Build Service) at the packages (RPM) building stage.
> That sounds interesting and is exactly what I had mentioned in my 
> previous email that I'd like to be able to consider for the centos 
> buildsystem as well. It would quite nicely add a test for 
> changeset-between-updates sanity testing ( in as much as what sanity 
> means to the CentOS userbase => things haven't changed ).

Adding to CentOS post-build tests isn't the right usage case for
upstream-tracker imho.

The information in the upstream tracker is based on "upstream". There
are any number of downstream modifications, such as ECC crypto
being ripped out everywhere @redhat.com and the fact that
there are no "reproducible builds" as long as AutoFu exists.

But there's no reason why additional interfaces cannot be analyzed
during rpmbuild, or post-build for the RPM upgrade challenged
(its really no harder than invoking an additional script at end of %install).

> We don't do any testing of that nature at the moment, we rely on 
> upstream having done such heavy lifting and we just aim to make sure we 
> are as close to their builds as possible.

You should be careful to point out that "upstream" for CentOS is @redhat.com.
That's a different meaning than commonly used for software distribution.

What I like about upgrade tracker is the deep vertical history. Its
quite difficult to assess portability and determine "minimal necessary version"
as a developer. One ends up getting blasted back to ancient releases
with poorly understood de facto mixtures of "stuff". The information
in upstream-tracker ie easily examined, and reasonable (from personal
experience maintaining 2 of the projects being tracked upstream-tracker
is identifying issues reliably. Sure there are both faux postives/negatives,
can't be helped.)

The equivalent developer decision for distros is choosing when to, say,
upgrade to openssl-1.0.0, and itemize a check-list of known issues
that need to be fixed moving forward. ATM, distro decisions are
largely ad hoc, where the old version is moved to compat-foo
(which largely guarantees no ABI breakage), but the issues
moving to a newer version of a package (and ensuring that
all pther packages have been updated) are largely implicit
rawhide-model processes which the details in the vertical history
in update-tracker can help identify.

73 de Jeff