-
Notifications
You must be signed in to change notification settings - Fork 11
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
Comments
I presume at a binary level, since otherwise you have to also require the gcc/binutils toochain? |
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 ;) |
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! |
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. |
The "create_interface_manifest" is (usually) going to use ELF sonames and How are you defining "interface" (if also talking about java)? FYI: rpm has had support for so name's since forever, and there is |
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.
The text was updated successfully, but these errors were encountered: