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."
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.
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.
A Government Is a Body of People, Usually Notably Ungoverned