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