diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-September/008097.html')
-rw-r--r-- | zarb-ml/mageia-dev/2011-September/008097.html | 274 |
1 files changed, 274 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-September/008097.html b/zarb-ml/mageia-dev/2011-September/008097.html new file mode 100644 index 000000000..6eaf17d13 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-September/008097.html @@ -0,0 +1,274 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Meeting tonight + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Meeting%20tonight&In-Reply-To=%3CCAONrEtaE2W6%2Buk%3DLh9cZNKB0SPbNx7itYHot9%2BaPLi%3DbBn2r9A%40mail.gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="008091.html"> + <LINK REL="Next" HREF="008099.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Meeting tonight</H1> + <B>Thierry Vignaud</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Meeting%20tonight&In-Reply-To=%3CCAONrEtaE2W6%2Buk%3DLh9cZNKB0SPbNx7itYHot9%2BaPLi%3DbBn2r9A%40mail.gmail.com%3E" + TITLE="[Mageia-dev] Meeting tonight">thierry.vignaud at gmail.com + </A><BR> + <I>Thu Sep 15 16:12:11 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="008091.html">[Mageia-dev] Meeting tonight +</A></li> + <LI>Next message: <A HREF="008099.html">[Mageia-dev] Meeting tonight +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#8097">[ date ]</a> + <a href="thread.html#8097">[ thread ]</a> + <a href="subject.html#8097">[ subject ]</a> + <a href="author.html#8097">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On 15 September 2011 12:48, Samuel Verschelde <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>> wrote: +><i> The problem is the situation is a lot more different that what the secteam at +</I>><i> mdv had to face. Would we only need to add "new" dependencies to updated +</I>><i> packages, that would be no big deal and we wouldn't make all this noise, we'd +</I>><i> just copy the deps and that's all. The problem is that we support migration +</I>><i> from Mandriva 2010.2 to Mageia 1, and that causes various situations where +</I>><i> *any* dependency of an updated package can be required to install from Core +</I>><i> Release, so we have to copy the full dependency chain ! +</I> +OK. + +><i> See Dave's recent mail +</I>><i> about bug 2317 that explains that in more details and gives the possible +</I>><i> solutions to this situation. +</I> +Note that his patch is broken as reported by testers... +"the patch (...) suggested some updates from Backports Testing, even though +the repository was not enabled" + +This is why I warned that playing with the algorithm regarding the various +combinaisons of setup media, enabled media, ... in my previous mail + +Anyway this patch cannot be accepted as it basically turns Mandriva Update +into rpmdrake, aka from "urpmi --auto-select --update" into: + "urpmi --auto-select --media='*/backports'" + +><i> I would be interested (really) by your opinion +</I>><i> about the solution to use among those he suggests, +</I> +see above + +><i> or even another one. +</I> +Suggestions: +- investigating using the equivalent of --searchmedia +- reusing the old connectiva upgrade infrastructure in the drakx installer + and release a patched installed (a mageia 1.1) that list mdv packages, remove + them prior to upgrading" +- patch perl-URPM so that foobar-X-Ymga is always newer than foobar-Z-Wmdv + +In the first case, we would go with something like r[1-4].diff +warning: unknown impact on startup time & RAM usage (in fact it's not +even tested) + +in the second case, that only cover the installer case, we should update +install::steps to favor mga over mdv. +See patches gi0X.diff (untested) +cf perl-install/install/share/upgrade/conectiva.10/* and +install:steps::upgrading_redhat() +But this means releasing an updated installer and updated ISOs... + +in the third case, that would mean patching URPM's Pkg_compare(), +ranges_overlap() +& rpmvercmp() and hoping nothing else open coded pkg comparison. +We could do what drakx do when upgrading redhat (which has not +been tested for quite a long time...), that is the live patching of URPM +as always +Should work. + +We may want to go the third way anyway for future updates... +And maybe doing the first one too. + +><i> As the problem is migration from Mandriva 2010.2, we could also try a 2 levels +</I>><i> solution : +</I>><i> - copy new deps the way mdv did, this will ensure fresh mageia installations +</I>><i> will never face an update problem because of a missing dep +</I>><i> - add to the errata that + warn users in MageiaUpdate by improving the error +</I>><i> message ("you can't install, maybe it's because you have old mdv packages on +</I>><i> your system, here is a way to solve your problem, do this and that..., or even +</I>><i> better catch the failure, do not show it, and try again with release media +</I>><i> added) +</I> +wrongdoing... + +>><i> 1)  we know there will be cases where it won't work +</I>>><i>      (see above those with the DVD media and not the full network +</I>>><i>      media, some new dependencies won't be found on the DVD, ...). +</I>>><i>      Multiply by those who have installed 32 DVD, 64 DVD, dual arch DVD, +</I>>><i> ... There are lots of different scenarios to deal with ... +</I>><i> +</I>><i> I think most of us are ready to ask users to add the full media set along with +</I>><i> updates media. +</I> +And still you won't catch the users that won't ask you, that won't read the doc, +... +You can increase the % of end users that will be covered but I fear you +won't even cover 50% of them. + +><i> The main difficulty is handling the transition, but this is +</I>><i> doable too. For people who might disable release media, this may be a problem, +</I>><i> but is there really an interesting use case for disabling release media and +</I>><i> activating updates media ? +</I> +Whether it's either interesting or not, some people just do that. + +Or play with /etc/urpmi/skip.list. +Another scenario I didn't bring attention upon.. + +>><i> 2) what's more, its not the time to do so, X months after the release +</I>><i> +</I>><i> 3.5 months, and the release will be supported for the coming 12.5 months, so I +</I>><i> think it's worth finding a solution now. +</I> +Sorry AFAIC after the release is too late by definition + +>><i> 3) MgaUpdate will be _much_ slower (compare the startup time +</I>>><i>     of rpmdrake vs MgaUpdate) because all synthesis +</I>>><i>    have to be parsed, then we need to compute / verify a far greater +</I>>><i>    number of potential updates ... (and it's _not_ O(n)) +</I>>><i>    just look at how much faster to start is mgaupdate vs rpmdrake) +</I>>><i>   It will also consume a lot more RAM +</I>><i> +</I>><i> Here I don't understand : can't MageiaUpdate make use of the Release media +</I>><i> only when it really performs the installation ? Or only if an update is +</I>><i> ignore/rejected because of a missing dep ? That's extra code, sure, but there +</I>><i> might be ways to do things so that extra CPU and RAM is used only when needed. +</I> + +>><i> 7) rpmdrake behavior may change in unforeseen ways +</I>>><i>     (because a a shared algorithm will changes) +</I>><i> +</I>><i> This one I can't tell, I don't know what shared algorithm you are talking +</I>><i> about. +</I> +you're suggering to alter mgaupdate behaviour +however it just uses rpmdrake's code with an update flag. +So altering the former's behaviour will alter the later's behaviour +I don't want to be rude but that "I don't know" is exactly why +I'm warning from the beginning + +>><i> Will you provides patches, test scenario and do the testing? +</I>><i> +</I>><i> Patches, not sure. Test scenarios is doable, testing too. +</I> +The faillure of the proposed patch should be a scenario for regression +testing btw. +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: r1.diff +Type: application/octet-stream +Size: 981 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment.obj> +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: r2.diff +Type: application/octet-stream +Size: 666 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0001.obj> +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: r3.diff +Type: application/octet-stream +Size: 708 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0002.obj> +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: r4.diff +Type: application/octet-stream +Size: 951 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0003.obj> +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: gi01.diff +Type: application/octet-stream +Size: 1077 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0004.obj> +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: gi02.diff +Type: application/octet-stream +Size: 1252 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0005.obj> +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: gi03.diff +Type: application/octet-stream +Size: 891 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0006.obj> +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: gi04.diff +Type: application/octet-stream +Size: 812 bytes +Desc: not available +URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0007.obj> +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="008091.html">[Mageia-dev] Meeting tonight +</A></li> + <LI>Next message: <A HREF="008099.html">[Mageia-dev] Meeting tonight +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#8097">[ date ]</a> + <a href="thread.html#8097">[ thread ]</a> + <a href="subject.html#8097">[ subject ]</a> + <a href="author.html#8097">[ 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> |