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
Michael Thomas wrote:
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)?
I see no problem in doing this for raidem-music (bug 190267), nor for worminator-data. But I think we should be very carefull with this, I dunno why I think this, but I'm afraid we might run into some kinda trouble.
Anyways concider this done for raidem-music.
Regards,
Hans
--Wart
Fedora-games-list mailing list Fedora-games-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-games-list
Michael Thomas wrote:
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
Erm, will this work? This means one can only do "make tag" for one branch won't plague be upset when you tell it to make something on FC-5 and the passed tag belongs to the devel branch?
Regards,
Hans
Hans de Goede wrote:
Michael Thomas wrote:
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
Erm, will this work? This means one can only do "make tag" for one branch won't plague be upset when you tell it to make something on FC-5 and the passed tag belongs to the devel branch?
I think we need to think this one over a bit more. For now I'm just going along with raidem-music with %{?dist}, I want to get that of my todo list. Then we can take our time to come up with something sane for this.
We might as well include packages in the discussion were upstream doesn't split content and engine and we want to split these.
Regards,
Hans
Hans de Goede wrote:
I think we need to think this one over a bit more. For now I'm just going along with raidem-music with %{?dist}, I want to get that of my todo list. Then we can take our time to come up with something sane for this.
We might as well include packages in the discussion were upstream doesn't split content and engine and we want to split these.
For the noarch data package that is the same in content between dists, go ahead and go distless for now. Send me requests directly, and I will *copy* the entire signed package from one dist tree to another. So you build it once and it will be replicated. We will need to formalize this process sometime later.
"make tag" failing on multiple branches is not a big problem if they are identical in content.
Warren Togami wtogami@redhat.com
Warren Togami wrote:
Hans de Goede wrote:
I think we need to think this one over a bit more. For now I'm just going along with raidem-music with %{?dist}, I want to get that of my todo list. Then we can take our time to come up with something sane for this.
We might as well include packages in the discussion were upstream doesn't split content and engine and we want to split these.
For the noarch data package that is the same in content between dists, go ahead and go distless for now. Send me requests directly, and I will *copy* the entire signed package from one dist tree to another. So you build it once and it will be replicated. We will need to formalize this process sometime later.
Okay, sounds good, so I basicly only keep a devel branch (no use for other identical branches then I guess, especially since I cannot tag them), build that and ask you to the result over to FC-5 (and possible others, but in this case only FC-5).
Wouldn't it be a good idea to use symlinks for this then, or can't the mirrors handle this? With symlinks we would get a real save in diskspace and bandwidth (only mirroring bandwidth, but still). The same (symlinks) can be argued for the i386 packages currently copied into the x86_64 repo.
Regards,
Hans
-
Hans de Goede -
Michael Thomas -
Warren Togami