diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-August/007627.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-August/007627.html | 146 |
1 files changed, 146 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-August/007627.html b/zarb-ml/mageia-dev/2011-August/007627.html new file mode 100644 index 000000000..94bb742ca --- /dev/null +++ b/zarb-ml/mageia-dev/2011-August/007627.html @@ -0,0 +1,146 @@ +<!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=%3C4E59FCCE.5050107%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="007615.html"> + <LINK REL="Next" HREF="007378.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Possible failure in our update process</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Possible%20failure%20in%20our%20update%20process&In-Reply-To=%3C4E59FCCE.5050107%40laposte.net%3E" + TITLE="[Mageia-dev] Possible failure in our update process">andre999.mga at laposte.net + </A><BR> + <I>Sun Aug 28 10:31:10 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="007615.html">[Mageia-dev] Possible failure in our update process +</A></li> + <LI>Next message: <A HREF="007378.html">[Mageia-dev] New version of mgarepo +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#7627">[ date ]</a> + <a href="thread.html#7627">[ thread ]</a> + <a href="subject.html#7627">[ subject ]</a> + <a href="author.html#7627">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Samuel Verschelde a écrit : +><i> Le jeudi 18 août 2011 17:46:06, John Balcaen a écrit : +</I>>><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>><i> +</I>><i> If I understand correctly, the problem is when several packages interfere with +</I>><i> each other. One thing that could help would be that after submit each update +</I>><i> candidate be checked by a script that would : +</I>><i> - detect BuildRequires that are present in updates_testing +</I>><i> - (needed ?) detect Requires that are present in updates_testing +</I>><i> +</I>><i> When there are such dependencies that come from updates_testing, it means that +</I>><i> they have not been pushed to updates yet, and that the update candidate that +</I>><i> is being checked must be treated with care. +</I>><i> +</I>><i> In kipi-plugins case, maybe following such a check, we would have decided to +</I>><i> ship it as part of the big KDE update and not as a standalone update. +</I>><i> +</I>><i> The updates policy would have to be adapted so that this check becomes part of +</I>><i> every update candidate validation. +</I>><i> +</I>><i> I'm not sure this is a good idea, but I'm sending it to you all the same :) +</I>><i> +</I>><i> Samuel +</I>><i> +</I>That's a good idea. It would avoid the situation where updates won't install +because of specified dependancies that are missing. But such cases won't +result in breaks, since such packages won't be installed. + +Let's assume that a package functions correctly with the latest updates +installed, but it breaks on a system based on the latest release, but without +all updates (or packages on the test systems) installed. + +If an update installs on a users' system, but it breaks, it indicates that +something required is not available. (Since it did work properly in a certain +context.) +In other words, the requires for the package aren't correct. +1) It could be that a package required is not specified (directly or indirectly). +2) It could be that a more recent (or different) version of a specified package +is required. + +It would be useful to have a script that monitors the package during execution +and determines what is called, to give us a list of what packages and versions +were used. +This will show us packages missing in requires. +As for versions, that is trickier. Requiring the versions used in the tests +would be excessive in many cases. However if this analysis is done before +releasing the update, it would help to more quickly correct broken updates. + +Hopefully this analysis helps a bit ? :) + +-- +André +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="007615.html">[Mageia-dev] Possible failure in our update process +</A></li> + <LI>Next message: <A HREF="007378.html">[Mageia-dev] New version of mgarepo +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#7627">[ date ]</a> + <a href="thread.html#7627">[ thread ]</a> + <a href="subject.html#7627">[ subject ]</a> + <a href="author.html#7627">[ 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> |