RPM Dependency Graph

Lomby writes "Following the spirit of the kernel schematics poster, I wrote a script that generates a diagram that depicts the rpm packages installed in your system, along with their dependencies. You can find more details and a download link at freshmeat."

Comments

Recursive loops

[flonker]

Ah, but does it handle recursive loops? ie. Package A v1.2 requires Package B, but package B requires Package A v0.9?

I've encountered that kind of thing way too frequently building stuff on Cygwin. Admittedly, RPMs are not the same as building from source.

Modified to support .debs?

[Other]

I wonder how hard this would be to modify to use debian packages and dpkg instead of rpm. Anyone taken a look at the source?

Re:Modified to support .debs?

[tconnors]

man apt-cache

cd /var/cache/apt/archives
apt-cache dotty *

google "i'm feeling lucky" on graphviz, and voila!

I have a feeling someone is working on packaging graphviz, but there was problems with true-type fonts....

Re:Modified to support .debs?

[jsse]

The above is non-graphical and apt-cache dotty * would return errors in some case. I made a little modification to make a full graph out of it:

apt-get install graphviz
apt-cache dotty `dpkg --get-selections | grep -v deinstall | cut -f 1` | dotty -

WARNING: it would take a lot of time. You may try `apt-cache dotty ssh | dotty -` just to see a simpler graph.

Artwork entitled, "Why to use apt-get"

[linuxbaby]

I would just put a title at the top of it saying:

"Why to use apt-get:"

Re:When will we get a proper packaging system?

[dmiller]

Secondly, no elegant way to integrate software that hasn't committed to one of the packaging systems into an architecture.

One does not have to "commmit to one of the packaging systems". Adding a single .spec file does not make adding Debian support any more difficuly. Your paragraph implies some sort of conflict between the two systems, where there is none.

Both RedHat and Debian both work great when you stick to rpms and debs, but just try installing the latest version of a piece of software that doesn't have an rpm or deb yet, and you run into a world of pain.

What is so difficult about installing unpackaged software? Redhat & Debian go out of their way to ensure that /usr/local is free for such things. If you mean that it is difficult for end-users to install such software, perhaps you should try getting them to compile and install unpackaged Windows software for a comparison.

That being said, it is very easy to turn most random tarballs off the net into RPMs, so long as they don't deviate too far from standard build/install procedures. Your typical ./configure && make && make install package can usually be turned into an RPM in about 5 minutes, without the need for patching.

Re:Lines and Dots

[SamBeckett]

They are all labeled, you numb nuts. Zoom in.

Re:When will we get a proper packaging system?

[hysterion]

Secondly, no elegant way to integrate software that hasn't committed to one of the packaging systems into an architecture. Both RedHat and Debian both work great when you stick to rpms and debs, but just try installing the latest version of a piece of software that doesn't have an rpm or deb yet, and you run into a world of pain.

Checkinstall makes this easy as pie.

$ ./configure
$ make
# checkinstall (*)

• builds your choice of a .deb or .rpm or Slackware package,
• installs it,
• saves it in (e.g.) /usr/src/packages/RPMS/<arch>,
• saves a .tgz of the sources in (e.g.) /usr/src/packages/SOURCES/.

It has served me quite well -- except the version I'm using (1.5.1) makes empty .tgzs. Not a big deal, and hopefully fixed by now.

(*) or else 'checkinstall your-install-script'

Checking which packages you never use

[Walles]

Shameless plug:

I have written a small tcl script (called pkgusage) that lists all your installed packages (RPMs or DEBs) together with the number of days ago you last accessed any of the files in each package. Thus, if you do "pkgusage.tcl | sort -n", packages which you seldom / never use will be at the end of the list.

It also checks dependencies between packages, so it won't tell you to uninstall a package that something else depends on.

If you are interested, get it here.