Many package managers in Linux distributions and BSD flavors track package dependencies. But before a package goes into a repository, it is investigated by a maintainer, who tracks the dependencies manually.

What software can be used to track package dependencies? Plain text files are not very good, because they are flat. Outliners that can keep data structured in trees are better, but not ideal, since dependencies do not always form a tree, sometimes they form a graph.

Please bear in mind that I'm not looking for something that can resolve dependencies automatically. I'm looking for an app that could store the dependencies between packages and allows queries to display the dependences for packages (like package managers).


Not sure I understand your question, but that is just what package managers do.

On Debian e.g. you can use

apt-cache depends <packageX>

to show packageX's dependencies, and

apt-cache rdepends <packageX>

to show reverse dependencies (packages that rely on packageX).

If that's not what you are looking for, maybe you could describe what you want to do?

  • This is not what I'm looking for. Assume there is an app that's not in the apt database yet. A maintainer investigates its dependencies by reading the documentation. What tool can he use to write down these dependencies if he has to deal with many packages? – Anonymous Oct 14 '09 at 11:14
  • I still don't understand what you mean by "track dependencies". Also, why do you insist doing it outside the package DB? Just add the package's repository to your repository list. You don't need to install it to do that. – sleske Oct 14 '09 at 12:53
  • Note: Please edit your question with clarifications, don't put them into comments. – sleske Oct 14 '09 at 12:54
  • sleske, because there are package managers that do not track dependencies. And because new software appears very often and I eventually want to use something that's not in the repository yet. I could figure out the dependencies of such software by reading docs, but I'd also like a handy tool to store this information. – Anonymous Oct 14 '09 at 13:04
  • 1
    The best way would be to build your own repository and make deb or rpm files, depending on your flavor of Linux, for any packages you wish to install. Then let the package manager do it's job. – 3dinfluence Oct 14 '09 at 17:45

I'm not that experienced with repository/package maintenance, but I've made my share of packages, either of internal software (the RPMs of common scripts and Nagios plugins that I put on all of the boxes) or of really new stuff that isn't available yet (Bacula in the CentOS repos is a full major version behind current).

I'm coming from an RPM based environment, so the terminology might not be the same, but the general idea should be...

I just keep a repository of every package I've ever built (in source form and as finished packages). As is required, I include dependency information in the RPM SPEC file, so it gets rolled into the RPM. When I want to know what the dependencies of a package I built were, I just "rpm -qpR foo.rpm", which lists the dependencies as reported by the RPM. If you want an exhaustive, recursive list you could just write a recursive script that uses that logic to check for dependencies of dependencies, etc.

If you're talking about lower-level, when I build packages I always keep the source under /buildroot, and for each package I generally keep two files: a screen log of the build process, and a "buildnotes" file. If there's any sort of weird dependency issues, I note it in buildnotes (which I generally roll into the package in /usr/share/doc/PACKAGENAME or some such location) - but for that stuff (human-readable dependencies, notes for packagers, etc - stuff more detailed than what the package format knows about dependencies) I haven't heard of any automated way of tracking it, save for a wiki or something in a makefile.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.