Re: RFC: Method for packaging game data
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
Attachments:
- signature.asc (application/pgp-signature — 198 bytes)