RFC: Method for packaging game data

[Jonathan Dieter]

On Wed, 2010-05-26 at 01:31 -0400, Stewart Adam wrote:
> I like this idea, but I think that if possible we should avoid the yum 
> naming rule. I doubt it will change anytime soon (we should ask a yum 
> developer), but I think that versioning is something much more solid we 
> should rely on for this mechanism.
> 
> I forget if providing a higher version of a capability means it gets pulled 
> automatically on yum update... If not though, this would work well:
> 
> Add Requires: uqm(data) to uqm
> Add Provides: uqm(data) = 1 to autodownloader
> Add Provides: uqm(data) = 2 to uqm-content
> 
> This way it will be satisfied with autodownloader, but prefer uqm-content by 
> version and by name. Either way, I guess it comes down to whether or not we 
> can trust the naming rule being around for a while. If the yum devs promise 
> it won't go away in the near future, then I think the plan you outlined is 
> great.

I think that, combined with Hans' suggestion of a subpackage, this would
probably be the cleanest method.

uqm Requires: uqm(data)
uqm-autodownloader (subpackage of uqm) Provides: uqm(data) = 1
uqm-content (in RPM Fusion) Provides: uqm(data) = 2

However, the one downside of this is that someone who had already
installed the game data using autodownloader will redownload the data
from RPM Fusion when they enable the repository and do a yum update.

Also, FWIW, I e-mailed Seth Vidal (and cc'd him in this email), and he
agrees with Thorsten that my original plan is too fragile, so we
probably don't want to depend on the naming rule.  Also, as Kevin
pointed out, the subpackage rule would trump it if we tried Hans' idea
without versions.

Another option (in a totally different direction) would be to have
PackageKit search for the data on the game's first run and then, if it
fails, use autodownloader as we currently do.  While this method would
avoid the double download problem, I don't feel that it's as elegant as
grabbing the game data in the same yum transaction as the game.

Jonathan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.rpmfusion.org/pipermail/rpmfusion-developers/attachments/20100526/33167cc2/attachment.bin