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

Hans de Goede j.w.r.degoede at hhs.nl
Wed May 10 21:44:32 UTC 2006


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?

Regards,

Hans




More information about the fedora-extras-list mailing list