Games submenus
by Christopher Stone
A few months ago I tried out GNOME to see if it has made any
improvements, and one thing I noticed is that the Games menu does not
have any submenus. As someone who installs every game available, this
made the menu quite unorganized. KDE has several submenus under games
such as Arcade, Card Games, Kids Games, Strategy etc.
I am wondering if it is possible to define some sub-categories we can
use for games to help clean up the games menu? Does GNOME support
these submenus? And is it possible to define our own set of submenus
for the Games menu? I think that since there are going to be many
more games added over the coming months and years it would be prudent
to implement some standards for this if possible as the Games menu is
already quite large, especially in GNOME.
17 years
Splitting content and engine for games where they come 1 one upstream tarbal
by Hans de Goede
Hi,
I've been pushing about one gcompris release / day the last few days (I
fixed a simple bug, but as these things go the fix introduced new bugS).
That means that I've been pushing a whopping 60Mb / day. Which IMHO is
not really acceptable. I know better testing -> less releases, but
sometimes things don't work like that. For example todays gcompris
release fixes a bug which is gnome-panel configuration dependent and now
amount of testing would have shown it with my panel config.
So I was thinking that I really need a seperate package for the
gcompris-data where most of the Mb's are. Just creating a seperate
sub-package won't help since that will get build with a new release of
the main engine package too and will have the same newer e-v-r,
resulting in the unchanged data still being updated.
So I could make 2 spec files, so 2 really seperate packages, both with
the same Source0, 3 problems:
1) ugly as hell
2) 2 large srpms, one of which will get updated each engine fix still
eating mirror bandwidth to mirror
3) this will take twice the space for srpms on mirrors
Now I had this idea which I would like to share:
Add a %define which makes building the data sub-package conditonal and
when a new release is needed with only engine fixes unset this define in
the spec so that the -data subpackage doesn't get rebuild.
Advantages:
1) No bandwidth wasted by mirrors mirroring huge data package for each
small engine bugfix
2) Even more bandwidth saved by people who regular do a yum update and
now only need to download the small engine update.
Disadvantage:
1) The SRPM will still be large and get updated as a whole for each
engine bugfix. This will take some bandwidth to mirror, but since not
many people actually download SRPM's their won't be much other
bandwidth usage caused by this.
2) Someone building from an SRPM which was just an engine fix release
will first need to set the define to true otherwise he will get an
incomplete (no -data package) build.
I think that the advantages out way the disadvantages, what do you think?
Regards,
Hans
17 years
game data packages
by Michael Thomas
At the last FESCo meeting the following packaging guideline was modified:
* Game music or audio content is permissible, as long as the content is
freely distributable without restriction, and the format is not patent
encumbered.
The restriction on ogg files was removed, but it's still not allowed to
ship mp3 files for game music.
This clarifies the rule for game music files, so it's clear now that
packages like
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190267 are ok.
However, brought up a concern about the disk usage from having duplicate
packages of this static content on the fedora mirrors. Clearly most
game data/music should be in a noarch package, but it still means that
each dist (fc4, fc5, fc6...) will end up with a duplicate package.
The recommendation to work around this is to _not_ use the %dist tag on
large, noarch, game data packages. This will result in identical
package filenames when built on each of the branches. While this won't
immediately reduce the disk usage on the mirrors, it will be one step
forward to helping solve the problem.
Does anyone else see any problem with prohibiting the %dist tag for game
data packages (unless the packager has a reasonable justification)?
--Wart
17 years, 1 month
Re: optional game music files
by Hans de Goede
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
17 years, 1 month