[Helidelinux-devel] Dependency management for software packaging

[Bennett T. <be...@ra...>]

I've not yet implemented it, but for my bent package manager I've
been thinking about how I want to do dependency management.

I've got some general thoughts, which give me an idea of what I want
to implement; I share them in case anyone else finds them
interesting. For compactness I'm going to express them as flat
statements with no waffling about "in my opinion", please take such
waffling as a global here, implied in everything that follows. Other
folks will want to do other things. With that said:

1. Manual expression of dependencies is not interesting. People
   usually don't bother to do it, and on the rare occasions when
   they do, they get it wrong oftener than not --- or it breaks when
   the name or version of package that provides some resource
   changes.

   Conclusion: all dependency management has to be completely
   automated.

2. Even automated dependency management is generally wrong. The most
   elaborate effort I've seen to date is made by rpm, it's got a
   great steaming heap of heuristics, and it still ends up making
   packages "depend" on e.g. /usr/local/bin/perl (which isn't
   provided on any normal system) because some example script,
   that's getting installed in /usr/share/doc/, starts off with such
   a #! line. And as I mentioned in point 1 above, dependency data
   gets stale as packages change names.

   Conclusion: dependancy data can be used to provide hints and
   advise, but it can't be trusted to be right.

Given the above, I'm planning on two kinds of dependency analysis.

I want to generate build-depends data; I'm currently thinking
something along the lines of running the build script fragment under
strace -efile -f, then analyzing the results to find all files
mentioned that were delivered by installed packages, and listing
those packages as build-time dependencies of this package. Then,
when re-building the package, if such build-time dependancies are
available, and if the build fails, use the build-time dependancy
data to generate suggestions that the builder can try.

The second sort of dependancy data will be install-time; for that, I
am thinking of a very simple approach: for every file in the install
tree, I'll do a strings -a; of the resulting strings, those that are
pathnames of files which exist on the current system, delivered by a
package, and which would not be delivered by the package being
installed, will be used to generate the install dependancy data, the
list of packages delivering the files named. In this analysis, files
in /usr/share/{man,info,doc} will be excluded. At install time, if
an allegedly-depended-on package isn't already present, a message
will be printed to stderr, but the installation will still proceed
and the exit status won't be affected by any dependancy failures.

And, of course, the dependency data should be sufficient to allow a
driver like "apt" to be written, if desired.

-Bennett