diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-September/008091.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-September/008091.html | 271 |
1 files changed, 271 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-September/008091.html b/zarb-ml/mageia-dev/2011-September/008091.html new file mode 100644 index 000000000..d8bbd510e --- /dev/null +++ b/zarb-ml/mageia-dev/2011-September/008091.html @@ -0,0 +1,271 @@ +<!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=%3C201109151248.01701.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="008119.html"> + <LINK REL="Next" HREF="008097.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Meeting tonight</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Meeting%20tonight&In-Reply-To=%3C201109151248.01701.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Meeting tonight">stormi at laposte.net + </A><BR> + <I>Thu Sep 15 12:48:01 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="008119.html">[Mageia-dev] Meeting tonight +</A></li> + <LI>Next message: <A HREF="008097.html">[Mageia-dev] Meeting tonight +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#8091">[ date ]</a> + <a href="thread.html#8091">[ thread ]</a> + <a href="subject.html#8091">[ subject ]</a> + <a href="author.html#8091">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le jeudi 15 septembre 2011 11:26:41, Thierry Vignaud a écrit : +><i> On 14 September 2011 17:50, Samuel Verschelde <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>> wrote: +</I>><i> > I tend to think that fixing MageiaUpdate would +</I>><i> > be a lot less work than the workaround we are trying to use which : +</I>><i> > - still needs work from the sysadmins +</I>><i> > - gives a lot of work to QA, that would be better used for testing the +</I>><i> > updates - forces us to link a lot of packages if we really want to make +</I>><i> > sure the update never fails +</I>><i> +</I>><i> For now, we are in the same configuration as @ mdv: +</I>><i> the updates must be self host, if they add new +</I>><i> requires, these must be added to the repository to update. +</I>><i> +</I>><i> This was decided a long time ago after thinking +</I>><i> +</I>><i> Some people have the media networks, ie all packages +</I>><i> can be fetched. +</I>><i> Others will have only DVD media and thus only have a subset +</I>><i> of packages. +</I>><i> Other disable certain media. +</I>><i> Other activate some other media (backports). +</I>><i> Some will have non-free and/or tainted enabled, some won't. +</I>><i> Ie there is no guarantee that a packet with new requires +</I>><i> can be updated on all machines as end users will have +</I>><i> a variety of packages subset. +</I>><i> +</I>><i> For almost 10 years MandrivaUpdate == "urpmi --update" +</I>><i> and not "urpmi --auto-select" +</I>><i> +</I>><i> I think that for the already released mga1 we should stick +</I>><i> to the known good old working method, the MDV's one, +</I>><i> rather than inventing a new quick & dirty thing quickly whom we'll +</I>><i> find subtle bugs along the incoming month +</I> +The problem is the situation is a lot more different that what the secteam at +mdv had to face. Would we only need to add "new" dependencies to updated +packages, that would be no big deal and we wouldn't make all this noise, we'd +just copy the deps and that's all. The problem is that we support migration +from Mandriva 2010.2 to Mageia 1, and that causes various situations where +*any* dependency of an updated package can be required to install from Core +Release, so we have to copy the full dependency chain ! See Dave's recent mail +about bug 2317 that explains that in more details and gives the possible +solutions to this situation. I would be interested (really) by your opinion +about the solution to use among those he suggests, or even another one. + +As the problem is migration from Mandriva 2010.2, we could also try a 2 levels +solution : +- copy new deps the way mdv did, this will ensure fresh mageia installations +will never face an update problem because of a missing dep +- add to the errata that + warn users in MageiaUpdate by improving the error +message ("you can't install, maybe it's because you have old mdv packages on +your system, here is a way to solve your problem, do this and that..., or even +better catch the failure, do not show it, and try again with release media +added) + +><i> +</I>><i> Some suggested removing the --update flag that MgaUpdate +</I>><i> "gives" to urpmi. +</I>><i> +</I>><i> I think most of them ignore what kind of problems that would bring, +</I>><i> they haven't made any tests at all: +</I> +That's why your mail here is very valuable : we can't guess them all (that's +what I meant with "no proof", I should have said "not enough information to +understand with our limited knowledge"). + +><i> +</I>><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 think most of us are ready to ask users to add the full media set along with +updates media. The main difficulty is handling the transition, but this is +doable too. For people who might disable release media, this may be a problem, +but is there really an interesting use case for disabling release media and +activating updates media ? And if there is one, + +><i> +</I>><i> 2) what's more, its not the time to do so, X months after the release +</I> +3.5 months, and the release will be supported for the coming 12.5 months, so I +think it's worth finding a solution now. + +><i> +</I>><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> +Here I don't understand : can't MageiaUpdate make use of the Release media +only when it really performs the installation ? Or only if an update is +ignore/rejected because of a missing dep ? That's extra code, sure, but there +might be ways to do things so that extra CPU and RAM is used only when needed. + +><i> +</I>><i> 4) that means that we must also update mgaonline to change the way +</I>><i> it computes if there any available updates (so that it +</I>><i> doesn't reject/ignore updates with missing Requires that can +</I>><i> be resolved from */release +</I> +Indeed + +><i> +</I>><i> 5) That means mgaapplet too will use quite a lot more time in +</I>><i> order to compute if there any updates +</I>><i> +</I>><i> 6) That means mgaaplet will consume more RAM when +</I>><i> it checks the updates (more exactly the son process it +</I>><i> forks) +</I>><i> however people are already complaining about RAM usage +</I>><i> in mgapapplet +</I>><i> +</I> +Not necessarily, if you do it in 2 steps : first compute list without release +media, and if updates have been rejected/ignored because of missing deps, try +again with release media. You will have that extra RAM and CPU usage only when +necessary. + +><i> 7) rpmdrake behavior may change in unforeseen ways +</I>><i> (because a a shared algorithm will changes) +</I> +This one I can't tell, I don't know what shared algorithm you are talking +about. + +><i> +</I>><i> 8) Fred Lepied, Frederic Crozat & Warly have removed quite +</I>><i> a lot of code everywhere since that policy went years (nearly +</I>><i> a decade ago) +</I>><i> that means there're a lot of tools that need potential patching +</I>><i> (urpmi, rpmdrake, mgaonline, ...) +</I>><i> for eg: checking for missing media, ... +</I>><i> +</I>><i> In short, it's quite a lot more work and quite a lot more risky than +</I>><i> "just" not using the --update "flag" as some think. +</I> +Indeed, I suspected that, I'm just trying to find a solution, and changing +MageiaUpdate and mgaapplet's behaviour is one of the solutions. + +><i> They only see that it will be less work for them (the +</I>><i> work previously done by mdv's secteam for years, that is check +</I>><i> for new introduced requires and if yes add them to the update media) +</I> +This is unfair, as said in various places in the previous weeks, migration +from Mandriva 2010.2 to Mageia 1 and the fact that Mageia 1 had a lot less +packages than Mandriva is what is causing the painful situation we have now, +we're just trying to find a way out of this nightmare. + +><i> It can just blow up in quite a lot of places: +</I>><i> - Updates that'll work for some and not for others depending +</I>><i> on which media are enabled +</I>><i> - slower Mgaupdate +</I>><i> - Mgaupdate consuming more RAM +</I>><i> - slower Mgaapplet +</I>><i> - Mgaapplet consuming more RAM +</I>><i> +</I>><i> IMHO it's obviously too risky to do such a major change and I failed +</I>><i> to see why we cannot work the mdv way. +</I>><i> +</I>><i> For the _next_ release, we can test & try to use --media and look if: +</I>><i> performance doesn't drop too much +</I>><i> But we'll still have the same issues: +</I>><i> - Disparate media (various DVDs flavour vs network, ...) +</I>><i> - Performance: the fact that one can have quite a lot media: +</I>><i> (3 (or 6 on biarch) updates media vs 9 (or 18 on biarch) media [1] +</I>><i> even 15 or 30 (biarch) media for those who activate +</I>><i> backport ledia [2]. +</I>><i> - algorithm consistency: it must work for those who enable backports +</I>><i> and those who don't, for those who enables tainted/non-free but not +</I>><i> non-free/tainted , .... +</I>><i> +</I>><i> This must be thought about. +</I>><i> Will you? +</I> +I'm trying. + +><i> Will you provides patches, test scenario and do the testing? +</I> +Patches, not sure. Test scenarios is doable, testing too. + +><i> +</I>><i> my 2 cents +</I> +Thanks + +Samuel +</PRE> + + + + + + + + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="008119.html">[Mageia-dev] Meeting tonight +</A></li> + <LI>Next message: <A HREF="008097.html">[Mageia-dev] Meeting tonight +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#8091">[ date ]</a> + <a href="thread.html#8091">[ thread ]</a> + <a href="subject.html#8091">[ subject ]</a> + <a href="author.html#8091">[ 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> |