[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: optional game music files

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]