optional game music files

Hans de Goede j.w.r.degoede at hhs.nl
Mon May 1 11:59:48 UTC 2006


Ville Skyttä wrote:
> On Mon, 2006-05-01 at 12:47 +0200, Hans de Goede wrote:
>> Wart wrote:
>>> Some examples of content which are not permissable:
>>>
>>> * Ogg/mp3 files
>>>
>>> Since these ogg files are part of the game, but not part of the upstream
>>> sources, are they still considered acceptable?
>>>
>> Since there has been no reaction for the last 12 hours, may I assume 
>> that no-one objects or?
> 
> IMO 12 hours is much too little time for doing something which appears
> to be directly against the packaging guidelines, especially considering
> that today is a holiday in lots of countries and probably considerably
> less people than usual are reading their FE mail.  Patience, please.
> 

I wasn't aware of the vacation bit, sure I'll wait a bit more.

> I'm not saying that this case is not acceptable for inclusion, but it
> sounds somewhat like being against the intended purpose or the "spirit"
> of that rule.  I guess it depends on exactly how optional those files
> are, how easy it is to properly install/remove them without them being
> rpm-packaged, and whether anyone would have any complaints about their
> inclusion if they'd be part of the upstream tarball which also contains
> the actual game.
> 

Thats exactly my problem with the possible explanation of these rules as 
this being unacceptable, if these files were in the same upstream 
tarball as the game engine and other gamedata nobody would be 
complaining. I've packaged plenty of other game packages containing 
music, how is this _any_ different except that the music is in a 
seperate tarball? Which is acutally good, because this means that the 
raidem-music pakcage will probably never have to change saving 
bandwidth! I would actually love to see other upstreams do similar 
splits, see below. However this whole story seems to penalize the good 
upstream behaviour of spitting of almost never changing content

> (There are some examples in the repo that I think would be better off
> handled by end users themselves and not packaged)

If the files are looked for by the package / game under 
/usr/share/%{name} I believe they should be packaged I don't want users 
dropping stuff there themselves potentially breaking upgrades, leaving 
cruft behind on uninstall, etc.

>, so one should apply
> criticism when/if looking for previous examples.  One example are the
> huge optional content blobs for uqm, of which only a subset changes
> between releases which can't be sanely handled in the current
> uqm-content package.  But the uqm case predates the guideline...)
> 

I know there are packages which could do with an upstream split in code 
and content so we could create seperate SRPMS for engine and content and 
thus easily (relative small download) upgrade the engine for bug fixes / 
new features. In general content tends to be much more static then the 
engines. I've actually been thinking about making 2 SRPMS both 
containing the same upstream tarball to fake this split. Unfortunatly 
this would take twice the space in the SRPMS dir on the mirrors, or I 
would have to create a split source tarbal myself.

Regards,

Hans






More information about the Fedora-games-list mailing list