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."
So anyone found any circular dependancies on their machine yet? You know it's only a question of how many. Whenever you have to install two (or more) RPMs at once, because you can't do them separately, in any order, you have a circular dependancy. Well done, RPM team!
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 ?
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 get easily lost amidst all this mess: /var/lib/dpkg/available | wc | awk '{print $1}'
grep '^Package: '
8990
I would just put a title at the top of it saying:
"Why to use apt-get:"
Would be nice to see / have one of these for debs. Most people dont worry too much about dependencies on Debian, apt-get being what it is, but would still be nice to see what requred what on my system.
Clutter everywhere.... Gota have Gtk+ , QT , imlimb , libgraphics , libjpeg, libgif, libHBig, Libtiff, libJohn, Libfruit, Libmonkie, libsuit, i wonder when somebody will set up a cvs for a linux distro. Kinda like FreeBSD does..
RPMs make it hard on the end-user. They should use something less complex, like BSD's port system. Perhaps by a dynamic reallocation of dependency variables, user friendliness could be upsized. The freedom to mix and match package systems from popular Linux distributions is a tantalizing feature that most WinXP users would kill for!
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.
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!
Because the deb distros are ancient as hell and won't even work on a modern computer anymore (XFree in particular).
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.
That would be useful for distribution maintainers. There was one in the FreeBSD ports collection involving a newer version of Bison and something else. In the end installing from packages was the only way to install. Not good. I remember that building linux from scratch required you to effectively build stuff twice to get around this.
finally made a script drawing the hell.
Linus wanted to run Unix but it was too expensive. I'm sure he could have afforded Windows, but who wants that anyway? ;)
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.
That sounds really cool -- I'll have to check it out the next time I try a deb-based disto. However, it still doesn't solve the problem of overcomplicated webs of dependencies and the lack of a single standard package system.
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 !
wc -l == wc | awk "{print $1}" :)
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?
The example file he provides is quite interesting - there seem to be three major dependency points; fileutils (which you'd expect), perl (ditto), and python (huh?).
I guess the python dependency comes from some of the configuration tools that Red Hat includes - can anyone confirm that?
Does anyone know where I can find a contrib rpm for the app ? The source doesn't compile on this machine...
/usr/ports/sysutils/pkg_tree
Manpage
Of course, it's not graphical, but it's the same sort of thing.
apt-get is far more logical method than that crud.
And you think yuor mom will ever want to use Linux with that type of installation nightmare!
Apples Darwin is not as sectioned as linux, but at least its not a nightmare yet.
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.
Why all that complaining about the lack of a single universal package systems when Debian has a tool to convert .rpm to .deb? That's almost as stupid as complaining about that there's not a single universal graphics format. As long as there are tools to convert from one to another, what's the problem?
I completely agree with you - windows installers can (and often do) spray files all over the place. Sure, windows has an add/remove control panel, but installers aren't required to place an entry there or on the start menu to make uninstallation easy. An installer could drop files all over the place and offer no way to clean them up. However, the windows model has two big advantages over linux in this respect:
1. There is a standard, accepted way to install and uninstall programs. Installer wizards for installation, the add/remove control panel to remove them. Installers can choose not to do this, but programs that don't make it easy to uninstall themselves don't endear themselves to the user, and offering an uninstall option is really easy to do.
2. When installing DirectX, you run one program and it installs everything. It doesn't offer an uninstall feature and new versions are often bug-ridden, a terrible combination, but you don't have to go out and install the pieces one-by-one yourself, nor do you have to worry about backwards compatibility.
(btw, yes I'm aware that you can download dx uninstall utilities off the net, but they don't come bundled. I'm also aware of how much code bloat its backwards compatibility creates.)
On the other hand, there are some big disadvantages that come with the windows model:
1. You must execute freshly downloaded code to install an app, except possibly in the case of an MSI. This isn't increasing the security risk, as you have to execute freshly downloaded code every time you run a freshly downloaded program anyway, but it does increase the chance that a bug in the latest version of the installer would prevent you from installing or would cause problems with the system.
2. Programs aren't required to register for uninstallation. One very good example is software that installs spyware, but conveniently forgets to uninstall it when you remove the program. I know we should all run ad-aware regularly anyway, but it's still not a good idea to leave the responsibility of uninstalling a program with the program itself.
What I'd like to see is a combination of the techniques commonly used on windows with the package management systems used on linux to create a better solution. The idea would be to have a system:
-That has a standard way of installing and uninstalling programs.
-Whose packages are made up of large groups of files providing a specific capability (functional applications) rather than a set of a few shared libraries or an executable.
-With a single package management application that is in total control of the install process, rather than leaving this important task to the individual applications.
-That makes it easy and convenient to uninstall _any_ installed application.
--nodeps and --force are dangerous, and if you are using them then you have done something seriously wrong.
Look, how hard is it to read the man page and find out that if you have, say, two packages. package-a.0.0.1.rpm and package-b.0.2.4a.rpm. Both have dependencies on each other. Reading the actual documentation that comes with rpm, you will find that you can do:
rpm -Uvh package-a.0.0.1.rpm package-b.0.2.4a.rpm
Surprise surprise! RPM will happily resolve the circular dependencies that exists between package-a & package-b, and will happilly install both of them without worry or fuss.
Now try "man man" do discover how to use this amazing resource known as a "manual"!
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 telling of the sorry state of /. moderation that the moderators didnt bother to check whether this basic fact was true or not...
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.
perhaps you should try getting them to compile and install unpackaged Windows software for a comparison.
Easy. If you have a source.zip, the user needs to follow these simple steps to compile a program on mingw:
If you want a start menu icon, drag the EXE on top of Start, then drag it into Programs.
Will I retire or break 10K?
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?
Print this out (if you can) and frame this post. This is THE REASON that Linux is not now nor likely to ever be a desktop OS.
I could not have come up with a better example of why Linux sucks ass than this post right here. Ok, well that may be fine for the real tinker toy OS hobbiests out there. But you have to see that this very thing will keep Linux off of virtually all end user machines!
Thank you! This is going on my wall of Linux Shame this afternoon.
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!
RPM? what's that then? haha debian phorev3r!!!!
Let's try to remember the programmer tried make RPM mananagement easier. A good idea, but I wish it came with RPM itself. Circular dependencies are a problem, but I think these others are bigger:
* Easy to find packages for everything. If I want the latest version of GCC for RedHat I probably have to go build it myself since it's not yet on rpmfind. Or wander through a maze of web pages to get the download link.
* It's hard to specify where I want the packages to go. As evil as it sounds, I'd like to choose where to install GCC, glibc, and such not let it up to some Linux standard committee over in Finland. I don't run a server, nor do I share my files with anyone, and it is my machine--so I want to be in control over where it puts things.
* RPM should probably support some sort of transaction so that an upgrade of GCC and glibc either all occurrs or none occurs. That way, I can safely ignore the dependencies.
* I'd also like to see a version of RPM that works with Windows, which would be much better than the Windows/Installshield stuff which only works sometimes.
* Perhaps its time for an XML based solution, which would be clearly readable, and avoids complicated perl/python/bash scripts and commands.
* Above all else, to package makers. If you require a certain package, either
a) Include the exact required package with it
b) Give me the EXACT link to download the package ( Don't make me fish for it through thousands of webpages, registrations, etc). (A problem more with Windows packages, though).
ok, a bit off topic but USB on debian is a piece of cake:
:)
compile your kernel of choice with usb modules
apt-get install usbmgr
not brain surgery indeed
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.
Comment removed based on user account deletion
--Curse you Debian users...
I always wondered what hell would look like. Somehow, that screenshot just looks too pretty.
Come on RPM guys... You can make a scarrier dependency hell than that, can't you? heh.. I just love all those nasty lines linking all those packages into such a tangled web.
Thank you very much, but I'll stick with installpkg, removepkg, and upgradepkg. Those are Slackware's package management tools for anyone who doesn't know. Take careful note: NO DEPENDENCY HELL.
[pseudo-packages] accomplish EXACTLY what you want.
As I understand it, pseudo-packages tell the package management system that something is installed without actually installing anything. This allows you to install whatever you want to handle that function without causing the package management system to freak out. I don't see how this, which seems to me like circumventing the package management system in order to install unpackaged software, accomplishes the unification of groups of packages into functional units that do things users can understand while eliminating giant webs of dependencies by discouraging single-library/executable packages.
Its the one thing which does make me go "Erm" when trying to convert local "MS is great"/"Did you pay for that software?"/"No, but I can't work linux" blokey to Mandrake.
/usr/local/ but be able to take the machine on their desk into their own hands occasionally. Yes, they'll bloat up their filestore and have a sysadmin chasing them to tidyup every so often, but thats the price of some control of your machine.
They can't and for the forseeable future, stick in "funky messing around application" and it works. Package dependencies, find that libqt installation, blah blah blah.
I think its more than that though... The constantly shifting sands of open source (try and get an older version of some linux packages is more than a chore) means that some apps will have to be tied to a specific version of some libraries. Yes, that might mean the application might have to come with _everything_ it needs to install (no dependencies at all not provided), and installed locally in a users system with the library paths mutated to override the system versions of the libraries required...
Its contrary to all the "lots of small apps put together" idea of unix, but if its a desktop, then the user should _not_ have root permission, not be able to install in
I think MS's days are numbered in the corporate world, preciously because of their lack of large scale network administration and control. Their OS is designed for individuals.
However, linux's shift into the desktop market also needs some compromise to match the simple "I want this app on my computer now" philosophy of Apple and Windows. Users should not have root permission and not have to mess with dependencies. However, that gives up some adminstration control of a machine, and thats the ultimate question which has to be answered before the issue can be addressed...
Radical Islam will commodify your discontent, and sell it back to you as religion.
Just as any other fundamentalist crap would do?
I am an actual user and I am actually using some of those tools. You are an anonymous coward, who has probably never used one of the unices you are flaming about.
The article talked about an admin gadget for linux distros, the thread discussed ways to solve dependency problems a better way than what you call "a real install". Your "real install" is a crude workaround done by additional tools installing dependent modules over and over again. This is neither a real solution, nor does it bear up against your own criteria.
You dropped some buzzword bullshit you refuse to expatiate. You are interested in wether GNU/Linux has a chance of becoming a desktop OS. I don't mind, because I am satisfied with the desktop OS of my choice, thank you.
there != they're
I think I understand what you're saying now. As I see it, my model is different from pseudo-packages in two different ways:
1. Pseudo packages _are_ regular packages - that is they are not marked differently. They are simply regular packages that depend on other packages but contain no files.
2. Packages can exist without belonging to pseudo-packages (or tasks).
I would alter these conditions.
Metapackages or tasks or whatever would be explicitly marked as being what they are and having greater significance than regular packages (options).
Packages would have to belong to a task - they could not be installed by themselves. This does not limit an author's ability to write new independent libraries - it enforces clear organization for clean integration. At first, when there are no applications that depend on it, it would be a part of the "test" task. If the library author wants to write an application that uses that library (or someone else wants to do the same), then that library would be included inside that application's task.
In addition to the ability for a user to view their entire system as a collection of several (not hundreds) of tasks that have clear definitions and purposes and manage them in a way that they can understand, it eliminates the existance of "ghost" packages left over from software that's been previously uninstalled but has not perfectly removed all of its guaranteed unique dependencies. Sure, you can do this with the system now by checking for packages that aren't depended on by anything and sorting through the list to see which ones you use to do something and which ones are merely unnecessary support libraries, but within this hypothetical system, the system will not allow this problem to occur in the first place.
It also makes possible distributing applications as complete tasks that contain all the packages necessary to use that application in one file. Download, install, it works. No more downloading a.rpm, finding out it requires the support libraries b.rpm, and c.rpm, downloading them and finding out c.rpm requires d.rpm and e.rpm, and then finding out that your system has a conflict between d.rpm and a currently installed packages. Yes, I know that debian already has support for automatic dependency checking and problem resolution, but only if the package management system can get a good look at all the dependencies and conflicts at once which means having all the packages somewhere in sources.list at the same time.
Depends. If a library is _incredibly crucial_ (not to mention huge) like glibc, then it would be included in the base task. When an updated version of glibc comes out, the old package would be migrated to the "legacy support" task and the new one would become a member of base. Authors of applications wouldn't include package X if it's a part of base. Glibc is a good example.
libopenssl is a different matter. Although it's becoming less and less common, there are still lots of machines that are not connected to a network, and thus don't neet secure sockets layer support for their applications. Because of this, libopenssl would not be included in the "bare bones" task. Task authors would have a choice here. For maximum compatibility, they would include libssl in their task as an "If you don't know what to download, download this." complete package. If the application needs a fairly common lib like libopenssl and the task author can safely assume that it will be on the system ("The user is downloading the task over and https connection or is already using software which already provides libopenssl") or is willing to take the risk, the author can choose not to include that package within his or her task. If a user downloads an application task that assumes the presence of a library that in fact is not present in the system, the system would pop up an error message to the effect of "This task does not contain all of the files necessary to install itself. Please obtain and install the complete version of the task." The wording of that message is very important. It says "please obtain and install the complete version of the task," not "please obtain and install a complete version of the task if one is provided, otherwise, resolve the dependency issue," - it takes for granted the existance of the complete task in a declaratory statement. It needs to be clear that if an author chooses to package his or her application, it is that author's responsibility to provide a complete task. Not all users can be expected to go out and resolve dependency issues by themselves and offering a complete task is the easiest way to deal with this situation from the point of view of the task author as well as the user. This is especially true if this model were widely adopted (a necessary precursor to success anyway) and producers of libraries (or other things commonly depended upon) started offering "task components." This way, the author would simply bind their application task componenet with the proper task components that it depended upon with a single command line (or click) and providing complete tasks would be virtually zero extra effort.
Yes, I'm aware that debian will automagically solve dependency issues, but only if the needed dependency is listed in sources.list. This may not be the case with an independently produced (or uncommon) dependency. This, it fosters dependence on the (excelently maintained but not under the user's control) debian package servers on the internet which does not offer the same level of mental security to the user as having everything on a cd and the application's web site. The situation is analagous to not being able to install many apps unless the windows update servers are up and running. This comparison doesn't perfectly reflect the situation, as windows update is offline a _whole lot more often_ than all the debian servers in the world are offline at the same time, but you get the idea.
Anyway, that's how apps would make sure they get the right libraries. The system would also be able to handle uninstallation while keeping dependencies in mind and making sure no extra bloat gets left behind on the system.
Example:
You don't have libA on your system, but you download taskB which, like any other properly produced "complete" task, contains the non-base libraries upon which it depends which in this case is libA. Everything is installed, and libA is now present on your system as a part of taskB. Then, you decide to download taskC which also depends on libA. Being the intelligent user that you are, you decide to download the "slim version" of the task that does not include libA. You tell the system to install taskC, the package management system detects that the required libA is already installed, a part of another task, and lets you install taskC. Now, let's say that you get bored with taskB and uninstall it. While processing your uninstall command, the PMS detects that a part of taskB, libA, is required by taskC. In order to process your command and follow the "no orphan packages" rule, libA is migrated from taskB into taskC, bringing the contents of taskC closer to the "complete version" of taskC (remember you downloaded the "slim version"). In this way, all applications continue to work properly and there are no conflicts. In the case that you had taskD, E and F installed that all used libA, ownership of libA would simply be moved into any single one of those tasks. In the case that "Joe Idunno Anythingaboutcomputers" was going through the same scenario and had downloaded the complete version of taskC (the smartest choice for him), the libA package from taskC simply would not be installed, and it would be noted in the DB that taskC does not have ownership over libA. Joe could then dump the taskC installer safe with (or in Joe's case, probably without) the knowledge that in the case he uninstalled taskB, libA from taskB would be moved to taskC, keeping taskC happy.
How's that sound?
This is an interesting discussing, but slashdot web posting has pretty high latency. Do you use MSN or ICQ chat services?