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.

Re:Modified to support .debs?

[Sam H]

There is also the problem that graphviz is free (beer) but not free (speech). Use Tulip instead. To get you convinced, here are some benchmarks.

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.

Cool project resulting from a big problem?

[Erpo]

This is a really neat project. I'm definitely going to download the code and generate that map, just to see how massively hairy it is. However, the fact that a project like this is newsworthy (i.e. produces such interest-generating and complicated output) seems to suggest that perhaps package management on linux (rpm, deb, whatever...) has just served to cover up a much larger problem.

Package management makes it possible and (depending on your point of view) easy to update an entire system using apt-get or up2date (or whatever). It also allows users to install and uninstall additional programs with a minimum of fuss. I think it's safe to say that without package management, system administration would be much harder. However, what's been created to support this system is a visually attractive, yet tangled web of dependencies and interrelations between software packages that make maintaining multiple versions of shared libraries for legacy as well as bleeding edge applications, creating backwards and forwards compatilbe software packages, and installing software that isn't aware of the package system in use on the machine a real pain and sometimes (for non-ultragurus) impossible.

In my opinion, what we really need is a single, standard package system for all linux-based distros. Chuck rpm, chuck deb, chuck them both and create a new one incorporating the best features of both, I don't care, but I think it really needs to be done. Also, I think a change in what we think of as a 'package' is in order, a minimum functionality so to speak. If a user cannot make the statement: "If I install (package X) then I can do (process Y)," then package X does is not significant enough by itself and should be incorporated into another package that requires/uses it. Examples:

If I install the "linux base" package, I can boot an absolutely bare-bones system.

If I install the "textual system" package, I will have access to a complete textual system, including a text-mode console login, text-mode editing tools (vi for example), a textual system configuration manager, etc...

If I install the "graphical system" package, I can boot into a system that is completely graphical all the way, including a graphical login, desktop environment, a graphical system configuration tool, a web browser, etc...

If I install the "office suite" package, I will have access to a word processing program, a spreadsheet editing program, and a presentation creation program.

Individual options (e.g. vi or emacs) within each package should be just that - options, not separate packages. Sure, a user may install more than he or she needs if packages are this "collective", but in my opinion, users would be much happier having an office suite installed when they only really need document editing capabilities than with a default OS install that takes up more than 1GB because it comes with everything preinstalled so regular users won't have to puzzle out the overcomplicated package managment system in order to install something else.

</rant>

Sound good?

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.

Re:When will we get a proper packaging system?

[PD]

Even experienced Debian users who repeatedly try to persuade me to abandon RedHat are forced to admit that they never did get USB working, and after a while you realize that they are more in-love with the theory of debian than the reality.

I run only Debian and I found it to be a piece of cake to get USB working.

The problem was that once my camera was recognized, the Linux kernel didn't know what to do with it. Does that make me more in love with the theory of the Linux kernel than the reality?

Re:When will we get a proper packaging system?

[Arandir]

Here's one tiny solution that will go a long way. I've never understood why all the distros don't use it:

No dependency should be a package! If kdelibs-3.0.3 requires qt-3 or greater, then the dependency should be "libqt.so.3", and not qt-3.0.3-17.i386.rpm. (of course, even that is oversimplifying, as many distros will break Qt up into five different packages).

The purpose of packages is to make the user's life easier, not to lock them into a particular lifestyle.