diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-August/007615.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-August/007615.html | 117 |
1 files changed, 117 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-August/007615.html b/zarb-ml/mageia-dev/2011-August/007615.html new file mode 100644 index 000000000..a66104f68 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007615.html @@ -0,0 +1,117 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Possible failure in our update process + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Possible%20failure%20in%20our%20update%20process&In-Reply-To=%3C201108272346.01091.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="007381.html"> + <LINK REL="Next" HREF="007627.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Possible failure in our update process</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Possible%20failure%20in%20our%20update%20process&In-Reply-To=%3C201108272346.01091.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Possible failure in our update process">stormi at laposte.net + </A><BR> + <I>Sat Aug 27 23:46:01 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="007381.html">[Mageia-dev] Possible failure in our update process +</A></li> + <LI>Next message: <A HREF="007627.html">[Mageia-dev] Possible failure in our update process +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#7615">[ date ]</a> + <a href="thread.html#7615">[ thread ]</a> + <a href="subject.html#7615">[ subject ]</a> + <a href="author.html#7615">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le jeudi 18 août 2011 17:46:06, John Balcaen a écrit : +><i> Hello, +</I>><i> +</I>><i> I noticed a problem with our update process thanks to bug #2450 [1] +</I>><i> Here we pushed a update to kipi-plugins package (due to a missing +</I>><i> requires) but the update ends up in a totally broken installation for +</I>><i> the end user which was not noticed by me (first in fault) & later by +</I>><i> QA. +</I>><i> +</I>><i> Currently every package built for updates are done against +</I>><i> core/release, core/updates and core/updates_testing, here when i +</I>><i> pushed kipi-plugins update, KDE 4.6.5 was already available in +</I>><i> core/updates_testing so as expected kipi-plugins get linked against +</I>><i> KDE 4.6.5 & not against KDE 4.6.3 (available in core/release) +</I>><i> Since most of actors of the QA are simply installing all packages from +</I>><i> core/updates_testing (like me) none of us noticed that it would break +</I>><i> without KDE 4.6.5 installed and when probably for first updates +</I>><i> people are using a « fresh Mageia 1» , with several packages in +</I>><i> updates_testing in the same moment we can't really expect them to +</I>><i> removed or reinstall/restore a Mageia 1 for every package available in +</I>><i> testing. +</I>><i> +</I>><i> A workaround (which could also ease work for QA people) would be to +</I>><i> have some temporary repositories as suggested by bolkm on irc, it +</I>><i> could be based on SRPM package name but for some project like KDE it +</I>><i> would need more hacks since RPMS needed to be builded in a specific +</I>><i> order. +</I>><i> +</I>><i> The QA user will be able to simply add a new media (like +</I>><i> urpmi.addmedia $mirror/core/updates_testing/packagetotest/ ) so it +</I>><i> will be more easy to test a package & *only* this one. +</I>><i> +</I>><i> Another solution is to rebuild the package when moving in on +</I>><i> core/updates_release but in that case the package tested by QA is of +</I>><i> course not the same as the one available previously in testing. +</I>><i> +</I>><i> What do you think ? +</I>><i> +</I>><i> +</I> +If I understand correctly, the problem is when several packages interfere with +each other. One thing that could help would be that after submit each update +candidate be checked by a script that would : +- detect BuildRequires that are present in updates_testing +- (needed ?) detect Requires that are present in updates_testing + +When there are such dependencies that come from updates_testing, it means that +they have not been pushed to updates yet, and that the update candidate that +is being checked must be treated with care. + +In kipi-plugins case, maybe following such a check, we would have decided to +ship it as part of the big KDE update and not as a standalone update. + +The updates policy would have to be adapted so that this check becomes part of +every update candidate validation. + +I'm not sure this is a good idea, but I'm sending it to you all the same :) + +Samuel +</PRE> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="007381.html">[Mageia-dev] Possible failure in our update process +</A></li> + <LI>Next message: <A HREF="007627.html">[Mageia-dev] Possible failure in our update process +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#7615">[ date ]</a> + <a href="thread.html#7615">[ thread ]</a> + <a href="subject.html#7615">[ subject ]</a> + <a href="author.html#7615">[ 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> |