[CentOS-devel] tracking ABI changes in C/C++ libraries
n3npq at mac.com
Tue Jul 20 09:05:49 EDT 2010
On Jul 20, 2010, at 8:38 AM, Karanbir Singh wrote:
> On 07/20/2010 10:31 AM, Andrey Ponomarenko wrote:
>> The examples of integration are:
> 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
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
More information about the CentOS-devel