I want to point a little problem about the version of a FOO software included in the distribution :
two ways for cauldron 1 ) Use always the last development release of FOO (beta or rc n+1) (means several downloadings of sources from the svn or git of the project, and several modifications of the spec file and patches) a) advantages for the packager : you are always able to build the rpm by adapting its spec file progressively, following the changes of the FOO software b) Problem for a tester of this FOO (n+1) software (I mean somebody wanting to contribute to the FOO project) : if you use cauldron to test it, you may encounter bugs and may not know if they belongs to cauldron or to the FOO (beta n+1) software c) Problem for the final user : when cauldron is frozen before the final release of Mageia, it may be frozen with a beta release of this software (n+1), still buggy ! and that's this buggy (beta or rc n+1) version which will be provided with the final release of Mageia. d) needs some acute attention from the packager : when a final release of the FOO (n+1)program appears and is packaged in cauldron : he MUST provide it in the updates repos of the last releases of Mageia (2011, 2012) 2) Use only the last stable version of FOO (n) in cauldron : a) advantages for the packager : needs less frequent modifications of the spec files and uses of the buildsystem b) problem for the packager : needs a huge work in one time to adapt the spec file from (n) version to (n+1) c) Problem for the tester contributer of the FOO program : he can never test the betas or release candidates with rpms from Mageia d) advantages for the final user : Mageia final release is always providing a stable release of the FOO software e) when a new stable version (n+1) of the FOO software appears, the packager may provide it to cauldron and to the updates repos of the last releases of Mageia (2011, 2012) in the same time BUT !!! these rpms haven't been tested as well as in first case (NB I'm not talking only of installing the packages but of the FOO program itself too, sometimes the FOO program needs some little adaptations for a particular distribution, and needs upstream feedback for this) A testing repo for the release of Mageia (2011, 2012) should be useful ! but it can be understood in two different ways : 1 ) It provides the rpm of the new stable release of FOO (n+1) (published after the last version of Mageia 2012, and having yet been built for cauldron) to test if the rpm is OK before providing it as an update for Mageia (2011,2012) (eventually needing modifications of the spec file or needing upstream bug corrections to adapt the software for Mageia specificity) or 2) It provides rpms of development versions (betas, rc) of FOO (n+1) to test and contribute to FOO project on a stable basis from Mageia before providing a rpm of the stable release of FOO (n+1) to updates repos and, in a second time only, the devs will adapt the spec files to Cauldron (the cauldron dev will not have to loose time with a buggy software !) To illustrate what I mean : An example with a software which has _always_ been _up to date in cooker _ following each beta or rc release, but unfortunately badly affordable in Mandriva releases: Mandrake 10.2 *hugin** 0.5-0.beta4.1* (not easy to use) BAD Mandriva 2006 *hugin* *0.5-0.rc1* (freezes) BAD 0.5 final release was never provided as update for Mandriva BAD Mandriva 2007.0 *hugin* *0.6.1* final release OK stable Mandriva 2007.1 *hugin* *0.6.1* final release OK stable Mandriva 2008.0 *hugin* *0.6.1* final release OK stable Mandriva 2008.1 *hugin* *0.7-0beta4.1* BAD Mandriva 2009.0 *hugin* *0.7.0-0rc6.1* BAD *hugin* *0.7.0* final stable release was never provided as update nor backport for Mandriva 2009.0 nor 2008.1 BAD nor provided for Mandriva 2009.1 BAD : Mandriva 2009.1 *hugin* *0.8.0-0.beta2.1* BAD *hugin 0.8* final release was never provided as update nor backport to 2009.1 BAD Mandriva 2010.0 *hugin 2009.2.0* (new version numbering) OK stable Mandriva 2010.1 *hugin* * 2009.4.0* _(quite_) OK stable *hugin* * 2010.0.0* published before Mandriva 2010.1 appears was not included in it nor provided as update nor backport for Mandriva *hugin 2010.2.0* published 10 october 2010 is in cooker .... *Please keep it and use it for Mageia* Sidetalk : I tried to compile hugin 0.7.0 or 0.8.0 final release for Mandriva 2008.1, it was not doable : from hugin 0.7.0 rc4 compiling hugin needed cmake : cmake(2.4.8) was buggy , not able to find the wxwidgets headers, and was never corrected nor updated for Mandriva 2008.1... cmake had been updated for Mandriva 2009.0 but not backportable as it in Mandriva 2008.1... I had to use a srpm of cmake from fedora (2.6.2-3fc9) and could at least do it for myself For French readers it has already been discussed on Mandriva forum : http://forum.mandriva.com/viewtopic.php?t=114405&start=0&postdays=0&postorder=asc&highlight=hugin <http://forum.mandriva.com/viewtopic.php?t=114405&start=0&postdays=0&postorder=asc&highlight=hugin> Hope this will help to think about repo trees ! Philippe
