Excessive package interdependency

[Nils Philippsen]

On Fri, 2003-12-19 at 07:50, seth vidal wrote:
> > You also want to remember bundles (or guess them for old setups), so that
> > you can say "has gnome" ok now in FC2 gnome has added x and y, stick up a
> > "The package groups you have selected have been expanded in this release,
> >  shall I also installl..."
> 
> I was thinking about this problem some and I've unfortunately come to
> the conclusion that tracking group information in some sort of database
> might be the only workable solution. Obviously a user could remove all
> sorts of packages that comprise a group, but if more and more of the pkg
> mgmt tools start to understand groups then maybe people will be more
> inclined to deal with them as a group not as individual packages.

I think one question is whether this gets tracked as part of the RPM
database or not.

> I've read and written code for determining if a group (comps.xml group)
> is installed or not. 
> 
> That being the case it'd be nice if we might be able to write down the
> group-is-installed policy now so people doing pkg mgmt and pkg-group
> mgmt have a rule to follow.
> 
> What I learned from bugging jeremy and from watching how groups got
> marked in r-c-p:
> 
> a group is installed if: all the mandatory packereqs are installed and
> all the metapackages are installed. Group reqs are not consulted.
> 
> any comments on maybe having anaconda write out a list of groups that
> are marked as installed when it finishes an install?
> 
> it'd be handy to know what a user selected group-wise.

When reading this thread I had the idea, that _if_ an RPM package could
"suggest" other packages/dependencies this should be doable. The
suggestions would consist all packages that can extend the functionality
of the package in question. It would be the task of the package
installing application to decide how to handle these; (potentially)
non-interactive ones like RPM could just ignore them (except for putting
them into the RPM database maybe ;-), interactive installers like s-c-p,
yum, ... could ask the user about it, e.g. only if a specific suggestion
doesn't already exist in the older version of the installed package
(thus eliminating asking about the same suggested package more than
once).

For that to work, a "suggestion" in package A should not only have the
name of the suggested package B, but also what the purpose of B is in
relation to A; e.g. for nautilus:

[...]
Suggest: nautilus-media >= 0.3.1 "Listen to audio files directly from Nautilus"
[...]

or even (I don't know if abusing the Requires tag is feasible):

[...]
Requires(suggest): nautilus-media >= 0.3.1 "Listen to audio files directly from Nautilus"
[...]

or the bloated version of it ("media" would be the tag by which the
installer app determines whether to ask about the package or not, along
with any "Obsoletes:" entry):

[...]
%suggest media
Obsoletes: music
Requires: nautilus-media >= 0.3.1
Description: Listen to audio files directly from Nautilus
[...]

A group could then just be a meta-package requiring all essential stuff
(e.g. libgnome, libgnomeui, ... for a GNOME meta-package) and suggesting
everything else that one might want to have or not.

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031223/0a38e2fe/attachment.sig>