Dynamic functionality testing

[rjschwei]

At present ISVs tend to depend on package names to determine if particular functionality is present. For example I recently ran across an application that tested for libaio to be present. Changing the package name to libaio1 cause the application installer to fall over and refuse to install the application. Additionally such testing is inevitably tied to the packaging commands used on a specific distribution which results in conditional code to decide which commands to use.

At the heart the application couldn't care less about the package name of course. What the application needs is to test that given functionality is present. Therefore, a cross distribution "interface" test that can be used at install time by ISVs would be very helpful.

[mwichmann]

I presume at a binary level, since otherwise you have to also require the gcc/binutils toochain?

[rjschwei]

Could be function or just library level.

One could envision that there is a "create_interface_manifest" tool that gets pointed at executables and shared libraries and creates an XML file of external dependencies. This XML file is then fed to a tool at install time "check_available_features".

The manifest creation could fall out of the app-checker with appropriate refactoring ;)

[mwichmann]

Sure, and some refactoring of infrastructure could also generate an executable and not count on the target to have one. I guess at this point we shouldn't be talking about implementation though, I just always seem to fall into that immediately :)

I get the impression many apps roll their own of some flavor of this (I'm particularly frustrated by the ones which go beyond looking for a java runtime and figure out that openjdk isn't good enough - which is mentioned only as a sample that sometimes the examination has to go deeper). Do we think there's a desire to centralize this? I would be happy with such a thing, but then I thought lsbinstall was a good idea too!

[rjschwei]

Most apps do roll their own and then distro vendors hear about it when something changes, thus I would think there is enough incentive across distributions to adopt a generic solution and include it in the distro.

[n3npq]

The "create_interface_manifest" is (usually) going to use ELF sonames and
(possibly versioned) symbols deduced from binaries. Is there really a need
to generate a Newer! Better! Bestest! XML representation when all the
necessary information is already present in executables and libraries?

How are you defining "interface" (if also talking about java)?

FYI: rpm has had support for so name's since forever, and there is
an rpm patch in Alt linux that collects the actual symbols used by
executables into a compact representation from which a subset
operation can be cheaply computed to ensure that needed ELF symbols
in an executable are present in a library.