diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-July/007016.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-July/007016.html | 181 |
1 files changed, 181 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-July/007016.html b/zarb-ml/mageia-dev/2011-July/007016.html new file mode 100644 index 000000000..1debcc59a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-July/007016.html @@ -0,0 +1,181 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Updates and 0 release + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Updates%20and%200%20release&In-Reply-To=%3C1311698525.9043.64.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="007006.html"> + <LINK REL="Next" HREF="007018.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Updates and 0 release</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Updates%20and%200%20release&In-Reply-To=%3C1311698525.9043.64.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] Updates and 0 release">misc at zarb.org + </A><BR> + <I>Tue Jul 26 18:42:05 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="007006.html">[Mageia-dev] Updates and 0 release +</A></li> + <LI>Next message: <A HREF="007018.html">[Mageia-dev] Updates and 0 release +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#7016">[ date ]</a> + <a href="thread.html#7016">[ thread ]</a> + <a href="subject.html#7016">[ subject ]</a> + <a href="author.html#7016">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le mardi 26 juillet 2011 à 15:26 +0300, Ahmad Samir a écrit : +><i> On 26 July 2011 13:22, Luc Menut <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">lmenut at free.fr</A>> wrote: +</I>><i> > Le 26/07/2011 12:40, Michael Scherer a écrit : +</I>><i> >> +</I>><i> >> Hi, +</I>><i> >> +</I>><i> >> while trying to work on the queue of update needing a push, I noticed +</I>><i> >> that almost all of them use a "Release: 0". +</I>><i> >> +</I>><i> >> Since this has a specific meaning ( ie, used for pre release, or svn +</I>><i> >> snapshot ), using this for updates is quite confusing, and I do not see +</I>><i> >> the reason for that. +</I>><i> > +</I>><i> > When it is used for prerelease (mainly in cauldron), the release 0 is +</I>><i> > usually associated with a svn or git rev. number, or date, or alpha, beta +</I>><i> > ... so it is not so much confusing with this use in update for official +</I>><i> > release. +</I>><i> > +</I>><i> +</I>><i> Exactly. (And I didn't see any users getting confused by that all +</I>><i> those years in mdv). +</I> +Likely because none of them know the specific meaning of using 0. + + +><i> >> +</I>><i> >> If the goal is to be sure that the software is still upgradable, the +</I>><i> >> whole %mkrel stuff should take care of that. And if not, we can rebuild +</I>><i> >> in cauldron to increase the release. +</I>><i> > +</I>><i> > We regularly used release 0 and subrel 1 in Mdv for the packages updated +</I>><i> > with the same version in official releases and in cooker (firefox, +</I>><i> > thunderbird, java-1.6.0-sun, ...), to be sure that the package from the +</I>><i> > official release will be updated by a update to the devel release or the +</I>><i> > next official release. +</I>><i> > +</I>><i> > we often used in such packages: +</I>><i> > %if %mandriva_branch == Cooker +</I>><i> > # Cooker +</I>><i> > %define release %mkrel 1 +</I>><i> > %else +</I>><i> > # Old distros +</I>><i> > %define subrel 1 +</I>><i> > %define release %mkrel 0 +</I>><i> > %endif +</I>><i> > +</I>><i> > regards, +</I>><i> > Luc +</I>><i> > +</I>><i> +</I>><i> Agreed. +</I>><i> +</I>><i> Besides, one can simply forget to bump the rel in Cauldron and the +</I>><i> issue will lay dormant until the next distro release is out and +</I>><i> upgrades fail, worse if the package is on the DVD and users get the +</I>><i> infamous urpmi-casacading-failure. +</I> +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 + +</PRE> + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="007006.html">[Mageia-dev] Updates and 0 release +</A></li> + <LI>Next message: <A HREF="007018.html">[Mageia-dev] Updates and 0 release +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#7016">[ date ]</a> + <a href="thread.html#7016">[ thread ]</a> + <a href="subject.html#7016">[ subject ]</a> + <a href="author.html#7016">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |