Splitting content and engine for games where they come 1 one upstream tarbal

[Paul Howarth]

On Wed, 2006-05-10 at 23:44 +0200, Hans de Goede wrote:
> Hi,
> 
> I've been pushing about one gcompris release / day the last few days (I
> fixed a simple bug, but as these things go the fix introduced new bugS).
> 
> That means that I've been pushing a whopping 60Mb / day. Which IMHO is
> not really acceptable. I know better testing -> less releases, but
> sometimes things don't work like that. For example todays gcompris
> release fixes a bug which is gnome-panel configuration dependent and now
> amount of testing would have shown it with my panel config.
> 
> So I was thinking that I really need a seperate package for the
> gcompris-data where most of the Mb's are. Just creating a seperate
> sub-package won't help since that will get build with a new release of
> the main engine package too and will have the same newer e-v-r,
> resulting in the unchanged data still being updated.
> 
> So I could make 2 spec files, so 2 really seperate packages, both with
> the same Source0, 3 problems:
> 1) ugly as hell
> 2) 2 large srpms, one of which will get updated each engine fix still
>    eating mirror bandwidth to mirror
> 3) this will take twice the space for srpms on mirrors
> 
> Now I had this idea which I would like to share:
> 
> Add a %define which makes building the data sub-package conditonal and
> when a new release is needed with only engine fixes unset this define in
> the spec so that the -data subpackage doesn't get rebuild.
> Advantages:
> 1) No bandwidth wasted by mirrors mirroring huge data package for each
>    small engine bugfix
> 2) Even more bandwidth saved by people who regular do a yum update and
>    now only need to download the small engine update.
> Disadvantage:
> 1) The SRPM will still be large and get updated as a whole for each
>    engine bugfix. This will take some bandwidth to mirror, but since not
>    many people actually download SRPM's their won't be much other
>    bandwidth usage caused by this.
> 2) Someone building from an SRPM which was just an engine fix release
>    will first need to set the define to true otherwise he will get an
>    incomplete (no -data package) build.
> 
> 
> I think that the advantages out way the disadvantages, what do you think?

Another disadvantage is that after a couple of engine-only pushes, the
SRPM from which the released game data package was built will no lnger
be available on the mirrors.

Paul.