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
