Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic functionality testing #7

Open
rjschwei opened this issue Apr 8, 2014 · 5 comments
Open

Dynamic functionality testing #7

rjschwei opened this issue Apr 8, 2014 · 5 comments

Comments

@rjschwei
Copy link
Member

rjschwei commented Apr 8, 2014

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
Copy link
Member

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

@rjschwei
Copy link
Member Author

rjschwei commented Apr 8, 2014

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
Copy link
Member

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
Copy link
Member Author

rjschwei commented Apr 8, 2014

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
Copy link

n3npq commented Jun 14, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants