With the OpenPKG "BuildEnvironment" tag (containing the *recursive*
"rpm -qa" outputs) we recently implemented the possibility to track the
complete "build ancestry" tree of a package.
Jeff noted that instead of an own representation (in our case as a
Lua table format construct) it would be much better to store those
things as real structured RPM meta data. Yes, of course! And here comes
another good reason why it would be ultimatively cool if RPM could
store such a "build ancestry tree": to support some sort of "transitive
dependencies".
Let me describe what I'm talking about: In OpenPKG we have packaged
Drupal, which depends on Apache+PHP and requires that PHP was built with
the PHP PCRE extension and that the PCRE in turn was built with UTF8
support. Technically, we implemented it this way:
Package Dependency
---------- ----------
drupal apache-php
apache-php::with_pcre = yes
pcre
pcre::with_utf8 = yes
apache-php %if "%{with_pcre}" == "yes" pcre %endif
This is usually sufficient in practice, as it at least triggers the
following build/install sequence if "drupal" is requested to be build:
1. "pcre" with "with_utf8=yes"
2. "apache-php" with "with_pcre=yes"
3. "drupal"
But this dependency specification is imprecise as it still allows one to
technically build the following way, too:
1. "pcre" with "with_utf8=no"
2. "apache-php" with "with_pcre=yes"
3. "pcre" with "with_utf8=yes"
4. "drupal"
This usually happens if step (1) was done in the past and steps (2)-(4)
are now done when "drupal" is requested. Here in step (2) the *wrong*
"pcre" is statically linked into "apache-php".
One possible and workable workaround is the following specification:
Package Dependency
---------- ----------
drupal apache-php
apache-php::with_pcre = yes
apache-php::with_pcre_utf8 = yes
apache-php %if "%{with_pcre}" == "yes" pcre %endif
%if "%{with_pcre_utf8}" == "yes" pcre::with_utf8=yes %endif
But this is actually rather ugly as the "apache-php"'s "with_pcre_utf8"
option is just a silly dummy for the "apache-php" package itself.
In case "pcre" would have N options this would lead to N additional
build-time options in all packages which require "pcre". Very ugly.
So, what would one expect here? Well, perhaps something like this:
Package Dependency
---------- ----------
drupal apache-php
apache-php::with_pcre = yes
apache-php/pcre::with_utf8 = yes
apache-php %if "%{with_pcre}" == "yes" pcre %endif
The syntax "N1/N2/.../Nx/<dependency>" is a transitive dependency
meaning that one requires that in the *build environment* of "Nx" one
requires that "pcre::with_utf8=yes" is satisfied and that in the *build
environment* of "N(x-1)" "N(x)" is satisfied, etc.
Or in this example: when "drupal" is build, it requires "apache-php"
to be installed (first dependency). Then it requires that "apache-php"
was build with option "with_pcre=yes" (second dependency). Finally, it
requires that at the time when "apache-php" was built, the dependency
"pcre::with_utf8=yes" was satisfied, too.
Or in short: if RPM would recursively track the build environment of
packages in its RPMDB, then both something like the BuildEnvironment tag
and those transitive dependencies would be easily possible. Without, it
is mostly impossible. BuildEnvironment we at least now solved through
some RPM Lua hacks. The other thing is impossible with RPM 5.0. But
perhaps this is something for RPM 5.1 ;-)
Sure, you can just call me crazy with all my esoteric feature requests.
But, sorry, that's just another example from practice where one would
like to be more precise and clean than what is currently possible with
existing RPM's feature set...
Yours,
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List [email protected]
