[Mageia-dev] Updates and 0 release

Tue Jul 26 18:42:05 CEST 2011

Le mardi 26 juillet 2011 à 15:26 +0300, Ahmad Samir a écrit :
+> On 26 July 2011 13:22, Luc Menut <lmenut at free.fr> wrote:
+> > Le 26/07/2011 12:40, Michael Scherer a écrit :
+> >>
+> >> Hi,
+> >>
+> >> while trying to work on the queue of update needing a push, I noticed
+> >> that almost all of them use a "Release: 0".
+> >>
+> >> Since this has a specific meaning ( ie, used for pre release, or svn
+> >> snapshot ), using this for updates is quite confusing, and I do not see
+> >> the reason for that.
+> >
+> > When it is used for prerelease (mainly in cauldron), the release 0 is
+> > usually associated with a svn or git rev. number, or date, or alpha, beta
+> > ... so it is not so much confusing with this use in update for official
+> > release.
+> >
+> 
+> Exactly. (And I didn't see any users getting confused by that all
+> those years in mdv).
+
+Likely because none of them know the specific meaning of using 0. 
+
+
+> >>
+> >> If the goal is to be sure that the software is still upgradable, the
+> >> whole %mkrel stuff should take care of that. And if not, we can rebuild
+> >> in cauldron to increase the release.
+> >
+> > We regularly used release 0 and subrel 1 in Mdv for the packages updated
+> > with the same version in official releases and in cooker (firefox,
+> > thunderbird, java-1.6.0-sun, ...), to be sure that the package from the
+> > official release will be updated by a update to the devel release or the
+> > next official release.
+> >
+> > we often used in such packages:
+> > %if %mandriva_branch == Cooker
+> > # Cooker
+> > %define release %mkrel 1
+> > %else
+> > # Old distros
+> > %define subrel 1
+> > %define release %mkrel 0
+> > %endif
+> >
+> > regards,
+> > Luc
+> >
+> 
+> Agreed.
+> 
+> Besides, one can simply forget to bump the rel in Cauldron and the
+> issue will lay dormant until the next distro release is out and
+> upgrades fail, worse if the package is on the DVD and users get the
+> infamous urpmi-casacading-failure.
+
+There is no need to bump the release in cauldron. 
+
+If I have the latest version X of package foo in cauldron, it would be 
+foo-X-1.mga2 , and if we push the same latest new version to stable
+( which should not happen much per policy ), it would be foo-X-0.mga1
+( with current practice ), or foo-X-1.mga1 ( with the proposal to change
+). 
+
+In both case, the upgrade path would not be broken, even in the event
+that foo is never rebuilt in cauldron, since 1.mga2 > 1.mga1
+
+
+The only potential issue would be that if we need to rebuild the package
+on stable, and not in cauldron, and so far, I didn't found any example
+of that except for wrong version updates were the current practice is to
+increase subrel. 
+
+Yet, the problem would also be there for regular non-version upgrade
+( ie, if we have foo-2-2.mga2 in cauldron and stable, and that we need
+to rebuild on stable and not on cauldron, we face the same problem ), so
+using 0 is a incomplete solution to the issue, and the only solution is
+to rebuild in cauldron, and such problem should better be detected by
+youri.
+
+So, the conclusion is that we should test ugprade rather than assuming
+that it will just work because we placed a 0 instead of a 1 somewhere. 
+
+Now, using 0 prevent us from having a simple way of seeing what
+prerelease we ship and that should be updated to latest stable ( as this
+seems to me quite desirable ).
+
+This is also inconsistent with the practice we had of backporting from
+cooker ( as the initial goal at Mandriva was to have 0 modifications
+from cooker to backports to reduce the load ). And if we ship something
+in update and in backports, we would have the same packages with 2
+different releases, and that doesn't seems a good idea.
+
+And as showed by Luc, this practice make us manually copy and and paste
+specific lines of code to specs to support it, and also requires to add
+a exception in the procedure. Since we always said to packagers "the
+release number start to 1", being inconsistent will likely make thing a
+little bit less easy to understand ( as every exceptions ).
+
+So we do have :
+- something that is not really needed, except in very rare cases that
+could be solved other ways most of the time ( and could be prevented too
+).
+- something that requires to add specific exceptions in 
+   - specs 
+   - procedures
+  with the added complexity it produces
+- something not consistent with existing practice of backports at
+mandriva and not consistent with regular packaging.
+
+So for theses reasons, I think the rule should be simplified, especially
+since the only reason is "we always did like that". 
+
+-- 
+Michael Scherer
+
+