[issue37] Debfoster like package removal

[Pascal Bleser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Arnold at Labix Tracker wrote:
> Daniel Arnold <arnomane at gmx.de> added the comment:

Hi Daniel. We started discussing this on #opensuse (me = yaloki).

Just a few more thoughts about it...

> Let's take the following situation: Like above someone installed a single                    
> Gnome app at at pure Qt/KDE desktop and now removes this app without removing                    
> its dependencies. The problem is that now a larger number of libs is on top                    
> level of dependencies but joe user has noe clue that they were installed                    
> together for a single purpose and thus should also be removed together.

This is something aptitude does, at least on Debian. While I do provide aptitude RPMs for SUSE
Linux, I never went beyond quickly testing and not liking it, though for other reasons (the UI ;)).

It seems that aptitude stores information about the automatically installed dependencies.
Say, you install gimp and you don't have any other GNOME libraries installed.
aptitude (like smart, apt, yum, yast2, y2pmsh, urpmi, ...) will automatically resolve the
dependencies and flag them for "automatic" installation.

The difference with other package management frontends (*) is that aptitude tracks that information.
When you later choose to remove gimp, aptitude "knows" that it should also flag the automatically
installed dependencies for candidate removal. Obviously, it has to check whether no other package
requires them in the mean time.

(*) with frontend I don't mean UI: apt/yum/urpmi/yast2/... all use rpm/dpkg to perform low-level
package management operations (install/remove/upgrade/query), so to me, they're "frontends" to rpm/dpkg

But this has a severe drawback: tt only works when you *always* use aptitude
If you switch package manager frontends (say, once with yum, once with smart, then with aptitude),
it won't work properly, because the other frontends don't track that information.
That tracking information should be stored at the package manager (rpm/dpkg) level, not at the
frontend level. Which implies that the package manager itself should provide those operations.

The other issue is that.. well... it's particularely complex to implement in a consistent, solid
manner. Many scenarios come to my mind where one should invest a lot of analysis and coding to make
sure it doesn't remove packages by mistake.
Already the following, rather common scenario is quite problematic:
1) smart install gimp
2) smart looks at the dependencies, and resolves them by flagging libgnome and a few others
3) later, you install another package that requires libgnome - say, python-gnome
4) later, you smart remove gimp
now... from the tracked automatic dependency information, smart knows that libgnome (let's reduce it
to this single dependency) has been installed automatically with gimp.
So, it must flag libgnome as a candidate for removal.
Next, smart needs to check whether another package requires libgnome.
That's certainly not _that_ difficult to implement (rpm -q --whatrequires libgnome + go through all
the "Provides" of libgnome and rpm -q --whatrequires those as well + filter out the package itself
(libgnome)).
Smart notices that python-gnome also requires libgnome. Hence, it won't elect libgnome for removal,
as it would break that dependency (which rpm wouldn't allow, anyway).

Fine. That's quite feasible, not too complex.
But now you "smart remove python-gnome", or, even more complex, you remove another package that's
the only one that requires python-gnome.
Yes, indeed:
1) that algorithm has to be recursive: for every automatically installed package that's candidate
for removal, smart has to check whether - if removing it doesn't break any dependency - itself is a
"top-level" package in the overall dependency graph of the package manager's database (rpm/dpkg)
2) how do you handle the tracking information ? the tracking data for the installation of gimp has
been removed, so... what do you do with libgnome ?

The real question is: is it possible to build an in-memory graph (tree) of the dependencies between
all the packages that are in your package manager database (hence, installed) ?

Once you're able to compute a full package dependency tree, it should be rather straightforward to
implement an algorithm that elects packages for automatic removal.

But there's another issue with that... some package should not be removed.
e.g. "kernel" - it probably doesn't even is explicitely required by any other package, yet, you
guess what happens when you remove it ;)
dpkg has a flag for such packages, don't remember the name right now, it's something like
"essential". A package that's flagged as "essential" cannot be removed (AFAIK).
RPM doesn't have that, unfortunately.
Ok, we could solve that by having a distro-specific list of "essential" packages, outside of the
package management database, e.g. as a plain text list of package names.

Ok, let's stop here ;-)
I guess that's enough to show the issue is very complex.

> But distros are writing install/uninstall logs that could be analyzed and            

Where have you seen that ?
Package managers don't have such logs.

> could be checked for removed packages. For these removed packages the                
> dependencies get also calculated and now you can reconstruct the root of a               
> dependency tree and can group the now independent top level dependencies                
> of the Gnome libs of our example together.   

Yes, but
1) package managers (rpm/dpkg) don't have such logs
2) it would still trigger a number of issues, as explained above

> So I now suggest an user interface where you have the top level packages like               
> a tree with subgrouping the dependencies that only belong to this package (in             
> that current installation, as the packages belonging to only one top package             
> can change if you install more packages).             
> So it would be look like this (in case the top leve application wasn't             
> removed):               
> [x][x] Application X               
>   ---[x] Lib X               
>   ---[x] Lib Y               
>   ---[x] Lib Z               

As far as the user *knows* what he is doing, such a tree could be shown to him in a UI.

...
> In case the top Application was already removed the interface looks like that         

Yes, but not all "top applications" may be removed:
~$ rpm -q --whatrequires kernel
no package requires kernel

cheers
- --
  -o) Pascal Bleser     http://linux01.gwdg.de/~pbleser/
  /\\ <pascal.bleser at skynet.be>       <guru at unixtech.be>
 _\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDY2UKr3NMWliFcXcRAmtBAJ9Jjz2WLruMU/6vHCWV4Y5ryjNMPQCghE8o
LLXLo3HY04iITap8r95N07w=
=NW2G
-----END PGP SIGNATURE-----