On 1/31/07, Hans de Goede <j.w.r.degoede(a)hhs.nl> 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.