On Wed, 2008-09-03 at 19:39 +0200, Hans de Goede wrote: > Michael Schwendt wrote: > > On Wed, 3 Sep 2008 18:58:35 +0200, Miroslav Lichvar wrote: > > > >> For example, why games data depend on binaries? > > > > I've also questioned that before. It boils down to a matter of > > convenience. It's packagers who say that the data pkgs are not usable > > without the game program, and therefore they want to avoid the > > scenario where somebody installs a game data pkg that doesn't result > > in a working game in the desktop menu. Hence game data and game > > program are tied to eachother in both directions. > > > > 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 ??) > > To avoid this the data packages depend upon the game binary, and vica versa the > game binary depends upon the data so that the data will get dragged in when > installing the game resulting in a working game. > > And no we will not just put them together, because re-releasing 300+ MB of > gamedata because the binary needs recompiling for a new lib is not cool! Wouldn't binary deltas make this issue just go away? We could put everything in the same package then and we wouldn't have to care about update sizes like this. Basically, if the only reason the packages are split in the first place is so you don't have to download everything all over again for a small update, then it seems like the correct thing to do is to make the update smaller, not complicate the package set... Dan > >> What do you think? Are loops something that we should try to avoid? > > > > Yes. IIRC, there are even some weird loops where after a package split > > a new sub-package depends on the main package and vice versa. > > > > Generally I agree, but their are exceptions, like game-engine <-> data > > Regards, > > Hans > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
