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 would just put a title at the top of it saying:
"Why to use apt-get:"
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!
They are all labeled, you numb nuts. Zoom in.
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?
Strange, I get a correct looking rpmgraph.dot file when running the programm but neato refuses to make a ps-file: warning, language ps2 not recognized If I change ps2 to ps in the Makefile, all I get is a zero byte ps-file. Well, there's probably something missing on my system, I should have a look at the rpmgraph. Oh, wait...
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.
With so many VB "certified engineers" out there, someone ought to do something to depict how the VB codes function.
Or better yet, how about something for MS's "Visual Suite" ?
That ought to make Billy the boy a very happy man.
Muchas Gracias, Señor Edward Snowden !
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.
Installed the Bubblemon yet?
/usr/ports/sysutils/pkg_tree
Manpage
Of course, it's not graphical, but it's the same sort of thing.
Take a look at the Portage system on gentoo, this may solve some of your problems.
"Unlike other distros, Gentoo Linux has an advanced package management system called Portage. Portage is a true ports system in the tradition of BSD ports, but is Python-based and sports a number of advanced features including:
dependencies,
fine-grained package management,
"fake" (OpenBSD-style) installs,
path sandboxing,
safe unmerging,
system profiles,
virtual packages,
config file management,
and more. "
My main problems with package systems are.
There not granular enough, you get everything or nothing.
Dependentancies are often compleatly mad and over strict.
There's no centrally intergrated package list (except rpmfind i suppose).
and
Distribuions package things up in all kinds of weird ways, If they done things to the LSB and decided on a name/location for each package then you could use a suse package on Mandrake without any major grief.
thank God the internet isn't a human right.
Then, when I try to get rpmgraph-core installed, it requires rpmgraph to be installed already.
No wonder only nerds only use linux: the average layman does not WANT to know what the word Recursive means.
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
Here's my RPM dependency graph, along with additional text to get past the lameness filter.
_
/ \
\_/
Comment removed based on user account deletion
It's a common mistake to imagine rpm packages as a big, uniform package base serving all distributions that use the format. It isn't. Each vendor can package software in a different way, built with different options and with different dependecies. Some distributions based on rpm are even migrating to a packaging layout more similar to Debian than Red Hat (e.g. libfoobar2 instead of foobar-libs).
So the answer is yes, you must have a different graph for each vendor.
As a side note, I've done that before using Gustavo Niemeyer's depmanager. If you don't work with a very restrict set of packages, the graph becomes very, very dense and confuse. But it's good to find dependency errors.
It's telling of the sorry state of /. moderation that the moderators didnt bother to check whether this basic fact was true or not...
> the packaging politics is entirely up to the distribution.
That should be "packaging policy". Yeah, I know, preview, yadda yadda.
I've said that before and I apologize to repeat myself, but I must insist in the fact that most people don't seem to understand the difference between mechanism and policy in package management. The package manager offers a mechanism, the distribution enforces policy.
That said, having a common package tool for all distributions wouldn't help. You can say most distros today standardized on rpm, but the packages are largely non-compatible because there's no common policy between them.
One of the policy rules could be, for example: "all runtime libraries must be packaged separately, and named differently according to binary compatibility". It makes sense, it works, Debian does that, Conectiva (which uses apt-get) does that, I think PLD and Mandrake are doing that. But for other distros it would mean a massive package layout change, and I doubt they would like to to that. (The reason for that rule is: if you upgrade a binary that needs a new version of a library that breaks binary compatibility with the previous versions, other binaries can still use the old library.) Before you say anything, the rpm ability to keep multiple version of a package installed is largely useless for this case doesn't help here.
What's so difficult is the incompatiblities between where RedHat (et. al.) decide a package should sit, and where the author believes it should sit. The worst example I can think of is perl and mod_perl. The RPM versions of perl insist on cluttering up /usr (along with every other thing in existance), but as soon as you go to CPAN and update something, voila... it wants a newer version of perl (sorry, I don't WANT to wait 6 months for RH to get around to releasing new rpms for bugfix versions of perl). Now, if you put it in /usr/local where it likes to be, suddenly you have two seperate module trees... perl will use /usr/local, but mod_perl will still use /usr. UGH! If you try putting it in /usr, you'll stomp ALL OVER the redhat dependancies, so when they DO release "updates", you'll backpedal versions.
/usr, if not.. it gets it's own subdirectory in /usr/local so it's contained. If you want to minimize your path to /usr/local/bin, just add symlinks.
I'm a big fan of the BSD ports system. If it was installed as part of the OS, it goes in
I wrote another script along the same lines. Yours is probably better, as I presume it checks the last-used timestamp on each file in the package. Mine just checked what was currently running (based on /proc), including libraries. It then checked the dependencies and gave a list of RPMs that you are running, RPMs that aren't running but are required, and RPMs that are candidates to uninstall.
The reports of the tcl script running a long time aren't surprising. Mine is a csh script, and it, too, will sit there for a long time before giving a result, and I don't think mine is doing as much work.
What application does this? [download from Internet to /Documents and Settings/Pinocchio Poppins/Desktop, then double-click package]
To install Nullsoft Winamp, you use the web browser to download winamp280_full.exe (a Windows SuperPIMP installation package). Then you double-click the file, which launches the install wizard.
Will I retire or break 10K?
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.
--
ALL YOUR BASE ARE BELONG TO US!
Yup, I agree. I've got a couple of software projects that are crossplatform. I released one binary zip file for Windows users that miraculously happens to work on every Windows OS. But maintaining Linux and BSD packages would be a nightmare, so I don't do it.
The difference is that Windows "packages" include redundant software. Those zip files or installshield executables include their own redundant copies of msvcrt.dll, vbrunxxx.dll, etc. Though this makes Windows packages a hell of a lot larger (in my case, 2.7Meg versus 300Kb), and makes package creation exceedingly difficult, it makes the users' lives a hell of a lot easier.
A Government Is a Body of People, Usually Notably Ungoverned
You are abusing the system and then complaining when it breaks. Use cpanflute2 (in the rpm-build) package to make building rpms of CPAN modules very very easy.
--Curse you Debian users...