Guideline Question

[Hans de Goede]

Christopher Stone wrote:
> On 1/31/07, Hans de Goede <j.w.r.degoede at 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.
> 

Agreed,

Regards,

Hans