Michael Thomas wrote:
Christopher Stone wrote:
> There is a package up for review, glob2, found here:
> 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
> 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
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
"...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.