Talk:How does Conary handle dependencies on abstract items?

From rPath Wiki

Q: I would like to know how Conary handles dependencies on, well I guess they could best be described as "interfaces"?

A few examples:

• An OpenGL program requires the presence of an OpenGL interface on the system, but is not dependent on any particular implementation (e.g. could be Mesa, SGI, or other commercial implementation)
• Java class files and java jar files require the presence of (a particular version of) the java runtime engine (e.g. Sun JRE, jikes, blackdown, libjava, etc.)
• Java source files require the presence of a java development kit (Sun, jikes, blackdown) and a build system (e.g. maven, ant, etc.) in order to be useful.
• Java apps usually require the presence of standard java extensions and other java libraries.
• Python compiled bytecode requires the presence of (a particular version of) python (which at least theoretically might not come from www.python.org).
• Python source requires python as well.
• Bash scripts require a bash interpreter (shell).

The central theme here is that none of the above are dependencies which reside in ELF (or a.out) format object files. I assume that analysis of object files is how Conary normally derives dependency information. Is there some mechanism for capturing dependency info not recorded in object files?

Bnordgren 16:56, 22 August 2007 (EDT)

A: Shared library ("soname") dependencies, though they are extremely richly expressed in Conary (including full symbol version and ABI information) are only a small part of the universe of Conary dependency management. So the lack of an ELF or other object file is not a major issue per se. There are mechanisms for capturing and for expressing many kinds of dependency information not recorded in object files. Each class of dependency lives in its own namespace.

For scripts, we automatically create a "file" dependency for the interpreter. We (regularize the use of "env" in order to make this dependency explicit and stable.) This is true for all interpreters that are able to use the leading #! mechanism.

For python dependencies, we use python introspection to determine actual python dependencies, and express them as such. These are python module dependencies; for python scripts, you will generally end up both with something like "file: /usr/bin/python2.4" and "python: sys". For python modules, we discover those dependencies both for source files and for .py byte-compiled files.

We dissect Java symbol tables and express that information as java dependencies. (Sometimes there are dependencies checked for within try blocks; we can't exclude those dependencies automatically.

We call Perl to discover perl dependencies. ("perl: Foo::Bar")

We use monodis to get Mono/CIL dependency information, and augment that with the XML interface version mappings and store it in "cil" dependencies.

We inspect ruby files to get ruby dependency information (in the upcoming Conary 1.2 release and the current 1.1.9x beta releases).

Unfortunately, php is such an ad-hoc language without formal namespace management that we do not auto-discover php dependencies. These need to be expressed as explicit dependencies on other packages (easily done) with what we call a "trove" dependency.

Conary does not implement fully abstract dependencies, because their ad-hoc semantics (rather, lack of semantics) is not stable. Instead, we have added classes of dependencies to handle explicit types of dependencies where this is possible, and focused on changing the approach otherwise. For example, when a particular use case (for example, building a particular software appliance) requires a set of packages that would not automatically be installed together because of dependencies, we have a facility called a "group" which is used to create consistent sets of packages known to work together. This is very different from the various package-name-list constructs in legacy package management systems, because they are fully version-managed, not just lists of names.

MichaelKJohnson 16:44, 23 August 2007 (EDT)

Comments