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

which vendor

[Anonymous Coward]

The problem with RPMS is when there are different dependencies for the same package depending on who it was packaged for.

So how do youy handle that, seperate grpah for eahc vendor ?

Lines and Dots

[Thomas M Hughes]

I made a program that could draw random lines and dots one time too. I never thought to submit it to Slashdot.

Actually, on a more serious note, a quick look for a screen shot brought up an image that was a bunch of lines and dots all looking pretty and stuff, and I'm sure it represented an RPM, but absolutely none of it was labled. So there doesn't appear to be any practical use for this at all.

And if you want something for the 'Oh, that looks neat and its meaningful too', I think you should stick to the Linux Kernel. It seems deeper than an RPM to me for some reason.

There is a reason.

[Anonymous Coward]

And the most important one of all.

Choice.

You don't like rpm? Use deb. You don't like deb? Use rpm. You don't like either? Create your own or compile from source.

As for the FUD about '..piece of software that doesn't have an rpm or deb..', well, that's what sacrifice you make when you choose to use a distribution as opposed to rolling your own system.

All that aside, the most blatant flaw here are the words 'Windows alternative'. Linux is Linux. It's not an alternative to anything. Don't mind the zealots. If you ignore them, they go away. ;)

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:When will we get a proper packaging system?

[Anonymous Coward]

It is pretty easy to make an RPM from almost any set of files that you can think of. All you really need to do is create an RPM "spec" file with a text editor. It is a short simple script that you can create which guides RPM in the packaging and installation of a piece of software. It is cookbook stuff, a no-brainer.

Take the time to learn RPM. It is an awesome sys admin tool. It is not just for intalling software. It is a complete configuration management system for software. You can verify checksums, check for missing files, find out which file belongs to what software package, verify your entire system. Too bad most people haven't taken the time to learn a little more about RPM. It is a real time saver.

I'm interested in hearing valid criticism of RPM from individuals who have worked with it and know its ins and outs. But really, unless you have that level of experience with RPM, all I can say is that you don't know what you are talking about.

Re:When will we get a proper packaging system?

[DerErsteMensch]

Hello!

I have a Mac OS X-Machine on my desk and there is fink, which allows me to use the debian package management system too. But I don't do it.

Why not steal a little bit from the Mac OS X ideas ?

There is a library folder, with all libraries in it. On Linux, this could like this: /Library/readline-1.2.0 /Library/readline-1.2.3 /Library/readline-1.3.1 /Library/perl-10.2.3
etc.
In order to use that stuff, there are only links inside the "normal" places. So there could be a link from /usr/bin/perl -> /Library/perl-10.2.3/perl/perl
Exception is the bare-bone stuff like inside /bin - certainly.

Application stuff, that's not started from the command-line like KDE or Gnome should through away their starter-stuff. This ugly stuff is borrowed from Microsoft and it's evil. On Mac OS X, there is an "Application" folder and every folder inside this has an .App suffix. If you click on this folder, the finder starts the applications with this path: /Application/_app-name-folder_.app/MacOsX/_the-bin ary_
All other stuff for the application like icons, translation files and that stuff is inside the _app-name-folder_.app.

I thinks it's pretty cool.

Re:Artwork entitled, "Why to use apt-get"

[jsse]

"Why to use apt-get:"

This is very funny but not being fair. :)

Any package system when connecting all packages with dependencies would look horrible.

Please refer to my previous post and create a similar dependencies graph in Debian and you'll see. :)

Nice and succinct. I like.

[2g3-598hX]

It's telling of the sorry state of /. moderation that the moderators didnt bother to check whether this basic fact was true or not...

Too many dependancies

[JamesGreenhalgh]

Try this on a debian (potato) box:

apt-get install jserv

Look in absolute horror as it trawls the kitchen sink down, including xfree.

This isn't debians fault, exactly - the package is fully featured, but it's useless for people who just want the core functionality.

The only place I've seen this done right, so far, is the FreeBSD ports system - mod_php being a good example, it asks you what support you want before checking dependancies.

I'd imagine the same goes for gentoo, which I will try one day - but I'm currently using SuSE because I've been through the whole slackware/roll your own/freebsd/redhat/etc mill so many times that I'm now happy to just use one that works, but isn't necessarily bang up to date with package versions.

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.