[NEW IDEA] Automatic removal of dependencies

[Panu Matilainen]

On Fri, 2006-04-28 at 08:43 -0500, Steven Pritchard wrote:
> On Fri, Apr 28, 2006 at 02:16:59AM -0700, Panu Matilainen wrote:
> > 3) It's something that will bring in additional functionality useful
> >    for some users. Nothing more than a hint that a depsolver (GUI) might
> >    list "you might additionally find some of these useful". An example of
> >    this would be xmms + it's myriad of plugins: xmms-sid isn't something
> >    most people will care about.
> 
> Stupid question, but how hard would it be for a depsolver to work this
> out in reverse?  For example, xmms-sid requires xmms, so when I'm
> installing xmms, notice that xmms-sid requires it, and suggest it as a
> possible enhancement?

I've thought about this - getting the reverse dependencies is not hard
at all, basically the depsolver could do the equivalent of this:

[root at weasel ~]# repoquery --whatrequires --alldeps perl-Kwiki
perl-Kwiki-Attachments-0:0.18-1.fc5.noarch
perl-Kwiki-UserName-0:0.14-3.fc5.noarch
perl-Kwiki-NewPage-0:0.12-3.fc5.noarch
perl-Kwiki-ModPerl-0:0.09-2.fc5.noarch
perl-Kwiki-Search-0:0.12-3.fc5.noarch
perl-Kwiki-Archive-Rcs-0:0.15-4.fc5.noarch
perl-Kwiki-Revisions-0:0.15-3.fc5.noarch
perl-Kwiki-Raw-0:0.02-2.fc5.noarch
perl-Kwiki-0:0.38-3.fc5.noarch
perl-Kwiki-UserPreferences-0:0.13-3.fc5.noarch
perl-Kwiki-Diff-0:0.03-2.fc5.noarch
perl-Kwiki-Users-Remote-0:0.04-2.fc5.noarch
perl-Kwiki-RecentChanges-0:0.13-3.fc5.noarch

What's problematic with this approach is that it only works for certain
types of packages, something resembling an application in other words.
Try it on a library and the results are probably not what you want. 

If there was a good way to distinguish application vs pure library
packages that might well be sufficient as a suggests/enhances mechanism.
Unfortunately it's not that clear. Taking perl-Kwiki as an example, it
lists "Development/Libraries" as it's rpm group, it doesn't belong to
any comps groups and it doesn't look like an application in the sense
that it doesn't put anything into your path (which is a very bad
heuristics anyway since many library packages have some utility
binaries) etc. It'd be very likely to be classified as a library of
sorts by any obvious heuristics to determine whether
"suggests/enhances"-reverse depends logic should be applied.

> I could see something like that being *really* handy with perl-Kwiki
> and the dozen or so plugins that are available in Extras right now.
> It would suck if I had to modify the main perl-Kwiki package every
> time someone packages up another plugin.  (That is, of course,
> assuming that someone other than me packages some plugins...  ;)

That's what Enhances is all about: the main package wouldn't have to be
aware of those other packages, those plugin packages would just have to
add "Enhances: perl-Kwiki".

	- Panu -