diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-September/008119.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-September/008119.html | 224 |
1 files changed, 224 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-September/008119.html b/zarb-ml/mageia-dev/2011-September/008119.html new file mode 100644 index 000000000..e408695cc --- /dev/null +++ b/zarb-ml/mageia-dev/2011-September/008119.html @@ -0,0 +1,224 @@ +<!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=%3C4E71D538.9050105%40gmail.com%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="008089.html"> + <LINK REL="Next" HREF="008091.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Meeting tonight</H1> + <B>Stew Benedict</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Meeting%20tonight&In-Reply-To=%3C4E71D538.9050105%40gmail.com%3E" + TITLE="[Mageia-dev] Meeting tonight">stewbintn at gmail.com + </A><BR> + <I>Thu Sep 15 12:36:40 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="008089.html">[Mageia-dev] Meeting tonight +</A></li> + <LI>Next message: <A HREF="008091.html">[Mageia-dev] Meeting tonight +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#8119">[ date ]</a> + <a href="thread.html#8119">[ thread ]</a> + <a href="subject.html#8119">[ subject ]</a> + <a href="author.html#8119">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>On 09/15/2011 05:26 AM, Thierry Vignaud wrote: +><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 don't know if it's the right meeting for it, but I would like us to talk +</I>>><i> again about bug 2317 <A HREF="https://bugs.mageia.org/show_bug.cgi?id=2317">https://bugs.mageia.org/show_bug.cgi?id=2317</A> that blocks +</I>>><i> updates +</I>>><i> We tried to previously chosen solution "link from Release to Updates", but we +</I>>><i> run into dependency nightmares such as in the end the solution would almost +</I>>><i> lead to copy the whole Release media into Updates. +</I>>><i> +</I>>><i> Without proof of the contrary, +</I>><i> what? +</I>><i> No it's not and I've already explained many times. +</I>><i> See below +</I>><i> +</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 updates +</I>>><i> - forces us to link a lot of packages if we really want to make sure the +</I>>><i> update never fails +</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>><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>><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> +</I>><i> 2) what's more, its not the time to do so, X months after the release +</I>><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>><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>><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>><i> 7) rpmdrake behavior may change in unforeseen ways +</I>><i> (because a a shared algorithm will changes) +</I>><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>><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>><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> Will you provides patches, test scenario and do the testing? +</I>><i> +</I>><i> my 2 cents +</I>><i> +</I>><i> [1] 3 (release / testing / update) x 3 (core / non-free / tainted) +</I>><i> [2] 5 (release / testing / update / backport / backport_testing) x 3 +</I>><i> (Core / non-free / tainted) +</I>><i> +</I>>><i> What I would like is a firm and courageous decision +</I>><i> no comment... +</I>><i> +</I>>><i> (we already talked a lot of +</I>>><i> this issue without much progress until now) that we set a date (soon) before +</I>>><i> which this problem will be completely solved, whatever the way. +</I>>><i> +</I>>><i> We really would like to have this issue solved and allow to concentrate on +</I>>><i> other important stuff (such as security updates for example). +</I>What complicates things is: + +1) we're adding new packages to updates for the mga1 exception +2) we're being quite loose with bumping versions for updates, apparently +patching is "too hard" for the new generation of packagers +3) we're trying to chase being able to do an update from mdv-2010.2 and +whatever those people might have installed as they use updates/backports + +-- +Stew Benedict + + +</PRE> + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="008089.html">[Mageia-dev] Meeting tonight +</A></li> + <LI>Next message: <A HREF="008091.html">[Mageia-dev] Meeting tonight +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#8119">[ date ]</a> + <a href="thread.html#8119">[ thread ]</a> + <a href="subject.html#8119">[ subject ]</a> + <a href="author.html#8119">[ 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> |