Contents

Introduction

Anitya has notified you that there is a new version of the widget package that you maintain. Great! Just slap the new version into the spec file, upload the new tarball, and call it a day, right? On this page, I review some issues you may encounter while updating a package and review possible solutions to those problems.

ABI Compatibility

When your package contains a library, you need to worry about backwards compatibility of the ABI (Application Binary Interface). When packages that use the library are built, assumptions about the ABI are baked into them by the compiler. If your package is updated without rebuilding the consuming packages, then they may suffer from weird failures at runtime.

Some upstreams manage this by giving their libraries an soname. If the soname changes, then you have no choice; all consumers must be rebuilt. It is wise to do mock builds in advance to ensure they all can be rebuilt successfully before starting any Fedora builds. It is considered good manners to announce soname changes in advance on fedora-devel-list, along with a plan to rebuild consuming packages. You may have to ask for proven packager help.

Even if the soname does not change, the package upstream may or may not have been careful to avoid backwards incompatible ABI changes. Fortunately, there are tools that can help determine if any such changes occurred. If not, then you can proceed with your update. If so, then rebuilding consumers is necessary. A suite of such tools are available in the libabigail package. Here is a workflow I often use.

  • Build the new version of the package in mock.
  • Change to the directory containing the built artifacts; e.g., /var/lib/mock/fedora-rawhide-x86_64/result
  • Visit koji and type the package name in the search bar
  • Select the latest build for the distribution of interest
  • Scroll down to x86_64 (or whatever the architecture of interest may be), and download the library package, the devel package, and the library debuginfo package. If the library package is not the main package, then also download the debuginfo for the main package. Place all of the downloaded files in the current directory.
  • Run abipkgdiff. If the library package is the main package, that looks like the following, where “old” and “new” refer to the package version downloaded from koji and the package version built in mock, respectively.

    abipkgdiff --d1 [old debuginfo] --devel1 [old devel] --d2 [new debuginfo] --devel2 [new devel] [old library] [new library]

    If the library package is not the main package, then add two more arguments:

    --d1 [old main package debuginfo] --d2 [new main package debuginfo]

If abipkgdiff reports that functions or variables were added, that is not a concern. What is concerning is the removal or alteration of functions or variables from the old version. Even then, the only consuming packages that have to be rebuilt (and possibly updated or patched) are those that use the functions or variables in question.