[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Dependency loops considered harmful?

Hash: SHA1

Miroslav Lichvar wrote:
> On Wed, Sep 03, 2008 at 07:39:38PM +0200, Hans de Goede wrote:
>> Actually its more about the removal scenario, lets say someone does:
>> df
>> yum install vegastrike    (drags in vegastrike-data)
>> df                        (who thats big)
>> <play vegastrike>         (hey that games sucks and eats up my HD-space)
>> yum remove vegastrike
>> df                        (WTF, why am I still missing 0.4 Gigs of HD-space ??)
> But that isn't much different from a case when I install any package
> with rich dependencies, say, gnome-session and after removing the
> package there will be dozens of packages left I didn't want.
> Actually, the loop may cause that I won't remove the game, because I
> forgot I've installed it and it doesn't show up as a leaf.
> Until yum or rpm is able to track packages installed only to satisfy
> dependencies, this will always be a problem. Why make the game data a
> special case?

A better move here would be to make better use of the yum "groups".
Right now, they're next to worthless. You've got the KDE group, the
Office group, etc. All of which install a ridiculous amount of software.

Applications that consist of multiple packages, such as the game
example, should be designated as a group rather than a looped
dependency. Then you can add or remove all packages related to it. As a
bonus, you can now allow games' data packages to be easily broken into
smaller packages (maybe models, levels, etc.) so that individual
components can be updated (if say, a single map is changed to eliminate
an exploit). This would mean that only the map package would need to be
updated (probably sub-1M) and not the entire data package (which could
be many megabytes).

- --

- --------------------
Stephen Gallagher
RHCE 804006346421761
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]