RFC: Method for packaging game data

Hans de Goede j.w.r.degoede at hhs.nl
Wed May 26 21:38:17 CEST 2010


Hi,

On 05/26/2010 08:31 PM, Jonathan Dieter wrote:
> 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.
>

Thanks for looking into this and asking Seth's opinion. I agree that the
solution described above is the best, so lets go for it :)

Regards,

Hans


More information about the rpmfusion-developers mailing list