Circular dependencies

[Michael Schwendt]

On Wed, 08 Nov 2006 17:02:57 -0800, Michael Thomas wrote:

> Michael Schwendt wrote:
> > On Wed, 8 Nov 2006 16:25:16 +0100, Ralf Ertzinger wrote:
> > 
> >>> It is OK as rpm/yum can sort this out at install / update / removal
> >>> time provided that both packages are in the transaction list.  The fun
> >>> part comes in BUILDING them.
> >> Thankfully it's just a runtime dependency.
> > 
> > The key question this raises is _why_ can't both packages be combined
> > into one?
> 
> If one of the packages contains large, static data files that don't 
> change often (such as game data), while the second package contains the 
> application code that depends on the existence of the first (such as a 
> game engine).  You don't want to push updates of a 50MB+ data file that 
> doesn't change for every minor bugfix in the engine.
> 
> Most of the large games in Fedora, however, don't do this with a 
> circular dependency, but rather by having the game data require the game 
> engine (or sometimes vice versa).

Well, there is no reason why game data actually "requires" the game
program before it could be _installed_. The important direction of the
dependency is "game program needs data, since else it would fail at
run-time" and not "data need a program". Think of it like a collection of
images without an image viewer. You would not make a wallpaper package
require an image viewer package, not even via a dependency on a virtual
capability. [Same with libraries, btw. ;-)]

A circular dependency is the wrong way of thinking here. Probably it's
only applied because end-users are confronted with data package names and
might try low-level commands like "yum install somegame-data" instead of
telling an installer to add/remove "somegame".

(In networked multi-machine installations it would even be plausible to
remove the dependency on the game data package, as it might be installed
only on a file server.)