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.) -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
