Christopher Stone wrote:
On 1/31/07, Hans de Goede <j.w.r.degoede@xxxxxx> wrote:
Michael Thomas wrote:
> Christopher Stone wrote:
>> There is a package up for review, glob2, found here:
>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225010
>>
>> The packager is putting the data files into a sub packge because of
>> this guideline in the Fedora Games SIG page:
>> "Package game files and data files separately, if possible, to reduce
>> size of
>> bugfix updates. This must be done if upstream packages game data in
>> separate
>> tarballs, and should be done even if upstream uses one tarball for
>> game source
>> and data. See Nazghul and tong for examples."
>>
>> This does not make sense to me. Shouldn't the data package be in an
>> entirely different spec file instead of just a subpackage of the main
>> spec file? If you are going to make a bug fix to the app, and do a
>> rebuild, the data package is also going to be upgraded at the same
>> time because they are both in the same spec file and get the same
>> release number.
>
> True, if the game data is in a subpackage then you don't gain much
> benefit during updates. In that case it's more of a cosmetic issue
with
> no real drawback. Though if Fedora ever starts using delta rpms, then
> we'd see an immediate benefit with no additional work.
>
> The next option would be to leave the data and code all in the same
> package, with no subpackage for the data. This is the default case
that
> we're trying to optimize by having -data subpackages.
>
> Another option, as you suggest, is to use separate spec files with the
> same source tarball. I like this option because it benefits the end
> users, but has the drawback of increasing the disk space consumption of
> the mirrors due to the source tarball being packaged twice in two
> separate src rpms. What's good for the users is bad for the mirrors, I
> guess.
>
Note that this has all been discusses on the extras mailing list already
(discussion started by me) and that the outcome in the case upstream has
only one tarbal was, that you must also have only one SRPM, or create 2
different tarbals for use in 2 different SRPM's yourself. IOW having 2
srpms with the same tarbal in them to get 2 really seperate data and
engine packages was deemed no acceptable.
> Ideally upstream would separate the game data and game code into
> separate packages, but that's not always an option.
>
Yes when the data is big that would be the best, we should try to
encourage the different upstreams todo the split in the big data cases.
> Perhaps we should clarify the 'should be done' sentence thus:
>
> "...and is recommended, but not required, even if upstream uses one
> tarball for game source and data" ?
>
I must admit that when upstream uses only one tarbal I never do a
seperate -data subpackage (see scorched3d for example) as that is
utterly useless then IMHO.
So should we encourage people to split up their packages in the same
SRPM even though its completely pointless? Perhaps we should update
the guidelines? I think pointing them to nazghul and tong as examples
is not a good idea since these packages do not accomplish anything by
breaking their data up into a subpackage of the same SRPM.
Agreed,
Regards,
Hans
_______________________________________________
Fedora-games-list mailing list
Fedora-games-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-games-list
