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
