Slashdot Mirror
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."
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.
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?
I love debian - in theory - but in practice, it can be a bitch to get working. 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.
So what are the problems with Linux?
Firstly, multiple incompatable packaging systems. There is no good reason why we need both debs and rpms other than petty politics.
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.
It is time for a new approach, hopefully one that is backward compatable with previous packaging systems, but which provides a unified distribution mechanism for binaries, while allowing different distributions to do things in their own way.
None of this is brain-surgery people!
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?
Ever wondered what a plot of a portion of the PGP web of trust would look like? Here it is.
sig2dot generates plotting data from the signatures in your GPG keyring; this data can be rendered by springgraph or graphvis. Many pretty sample plots on the page.