Dependencies and embedded dependencies PDF Print E-mail
User Rating: / 0
PoorBest 
Written by Michael Felt   

Ouch! and Bother!

The last two weeks I have been making time for a patch (cpython sees it as a new feature) for python. And maybe a few other things - such as the latest httpd and associated apr and apr-util.

I was having some surprising issues with libxml2 and libexpat - they just seemed to be off. I have not figured out where the libxml2 issues come from - but libexpat was a collision from 'old-style' apr-util (version 1.5.4) that has libexpat embedded, and the needs for python and libexpat - that needs to be coming 'from the system'.

APR-UTIL had libexpat-1.X embedded

In early January 2016 I rebuilt the (then) current httpd-2.2.X release and also updated apr and apr-util. This month I was not consciously aware of the version (better ABI) of libexpat. APR-UTIL had libexpat-1.X included (embedded) in it's sources and so it was also creating the library libexpat.a with the shared library libexpat.so.0. The 0 (zero) in the name is part of the ABI designation.

Currently expat is at version 2.2.5 and the shared library name is libexpat.so.1. When I installed the new aixtools.expat.2.2.5.I I got a warning about /opt/lib/libexpat.a now being owned by the new fileset. And since everything continued to work normally - I was not not overly concerned. Only a week later - when I rebooted the portals did I get messages about libexpat.a(libexpat.so.0) not being available. About 30 minutes after the reboot was up I was able to examine an old backup and take corrective action. (And the portals are running again).But this was not 'fine'.

So what?

Well, by itself - this is not really interesting. Although, it is a sign of good practice that more OSS projects are stopping with "embedding" shared library sources into their projects. And, perhaps that many of these packages everyone seems to depend on - are now stable enough that projects no longer feel they must embed - to maintain their package stability.

For me!

Going to be much more alert when I get a warning from installp that a file was already owned (read used to be owned, because the new package has taken claim already) and examine where it came from - and check if there is an ABI change. When the ABI versions are the same - it is not 'pretty' that the file ownership changed - but it is not suppossed to have any effect on already installed versions.

Additionally, I am going to need to redo the installation checks to keep an old ABI - and manually add that back into the new archive.

The last warning - to you!

When you install software using installp - if you see a warning about ownership change - make sure you verify existing applications continue to work. And remember, installp only warns about files installed using installp. Files installed using an alturnate install manager (e.g., RPM) do not warn about installp (managed) files they overwrite. Also, installp does not warn about RPM managed files it overwrites. In short - using two different install managers is almost certain to fail eventually! And the chance is greater now that more OSS packages are dropping their old habits of embedding the libraries they need.

 
< Prev   Next >