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. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
