[Mageia-dev] Updates and 0 release

Michael Scherer misc at zarb.org
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



More information about the Mageia-dev mailing list