summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/2011-September/008097.html
diff options
context:
space:
mode:
Diffstat (limited to 'zarb-ml/mageia-dev/2011-September/008097.html')
-rw-r--r--zarb-ml/mageia-dev/2011-September/008097.html274
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 &lt;<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>&gt; wrote:
+&gt;<i> The problem is the situation is a lot more different that what the secteam at
+</I>&gt;<i> mdv had to face. Would we only need to add &quot;new&quot; dependencies to updated
+</I>&gt;<i> packages, that would be no big deal and we wouldn't make all this noise, we'd
+</I>&gt;<i> just copy the deps and that's all. The problem is that we support migration
+</I>&gt;<i> from Mandriva 2010.2 to Mageia 1, and that causes various situations where
+</I>&gt;<i> *any* dependency of an updated package can be required to install from Core
+</I>&gt;<i> Release, so we have to copy the full dependency chain !
+</I>
+OK.
+
+&gt;<i> See Dave's recent mail
+</I>&gt;<i> about bug 2317 that explains that in more details and gives the possible
+</I>&gt;<i> solutions to this situation.
+</I>
+Note that his patch is broken as reported by testers...
+&quot;the patch (...) suggested some updates from Backports Testing, even though
+the repository was not enabled&quot;
+
+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 &quot;urpmi --auto-select --update&quot; into:
+ &quot;urpmi --auto-select --media='*/backports'&quot;
+
+&gt;<i> I would be interested (really) by your opinion
+</I>&gt;<i> about the solution to use among those he suggests,
+</I>
+see above
+
+&gt;<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&quot;
+- 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 &amp; 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()
+&amp; 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.
+
+&gt;<i> As the problem is migration from Mandriva 2010.2, we could also try a 2 levels
+</I>&gt;<i> solution :
+</I>&gt;<i> - copy new deps the way mdv did, this will ensure fresh mageia installations
+</I>&gt;<i> will never face an update problem because of a missing dep
+</I>&gt;<i> - add to the errata that + warn users in MageiaUpdate by improving the error
+</I>&gt;<i> message (&quot;you can't install, maybe it's because you have old mdv packages on
+</I>&gt;<i> your system, here is a way to solve your problem, do this and that..., or even
+</I>&gt;<i> better catch the failure, do not show it, and try again with release media
+</I>&gt;<i> added)
+</I>
+wrongdoing...
+
+&gt;&gt;<i> 1) &#160;we know there will be cases where it won't work
+</I>&gt;&gt;<i> &#160; &#160; &#160;(see above those with the DVD media and not the full network
+</I>&gt;&gt;<i> &#160; &#160; &#160;media, some new dependencies won't be found on the DVD, ...).
+</I>&gt;&gt;<i> &#160; &#160; &#160;Multiply by those who have installed 32 DVD, 64 DVD, dual arch DVD,
+</I>&gt;&gt;<i> ... There are lots of different scenarios to deal with ...
+</I>&gt;<i>
+</I>&gt;<i> I think most of us are ready to ask users to add the full media set along with
+</I>&gt;<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.
+
+&gt;<i> The main difficulty is handling the transition, but this is
+</I>&gt;<i> doable too. For people who might disable release media, this may be a problem,
+</I>&gt;<i> but is there really an interesting use case for disabling release media and
+</I>&gt;<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..
+
+&gt;&gt;<i> 2) what's more, its not the time to do so, X months after the release
+</I>&gt;<i>
+</I>&gt;<i> 3.5 months, and the release will be supported for the coming 12.5 months, so I
+</I>&gt;<i> think it's worth finding a solution now.
+</I>
+Sorry AFAIC after the release is too late by definition
+
+&gt;&gt;<i> 3) MgaUpdate will be _much_ slower (compare the startup time
+</I>&gt;&gt;<i> &#160; &#160; of rpmdrake vs MgaUpdate) because all synthesis
+</I>&gt;&gt;<i> &#160; &#160;have to be parsed, then we need to compute / verify a far greater
+</I>&gt;&gt;<i> &#160; &#160;number of potential updates ... (and it's _not_ O(n))
+</I>&gt;&gt;<i> &#160; &#160;just look at how much faster to start is mgaupdate vs rpmdrake)
+</I>&gt;&gt;<i> &#160; It will also consume a lot more RAM
+</I>&gt;<i>
+</I>&gt;<i> Here I don't understand : can't MageiaUpdate make use of the Release media
+</I>&gt;<i> only when it really performs the installation ? Or only if an update is
+</I>&gt;<i> ignore/rejected because of a missing dep ? That's extra code, sure, but there
+</I>&gt;<i> might be ways to do things so that extra CPU and RAM is used only when needed.
+</I>
+
+&gt;&gt;<i> 7) rpmdrake behavior may change in unforeseen ways
+</I>&gt;&gt;<i> &#160; &#160; (because a a shared algorithm will changes)
+</I>&gt;<i>
+</I>&gt;<i> This one I can't tell, I don't know what shared algorithm you are talking
+</I>&gt;<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 &quot;I don't know&quot; is exactly why
+I'm warning from the beginning
+
+&gt;&gt;<i> Will you provides patches, test scenario and do the testing?
+</I>&gt;<i>
+</I>&gt;<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: &lt;/pipermail/mageia-dev/attachments/20110915/e36848de/attachment.obj&gt;
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: r2.diff
+Type: application/octet-stream
+Size: 666 bytes
+Desc: not available
+URL: &lt;/pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0001.obj&gt;
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: r3.diff
+Type: application/octet-stream
+Size: 708 bytes
+Desc: not available
+URL: &lt;/pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0002.obj&gt;
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: r4.diff
+Type: application/octet-stream
+Size: 951 bytes
+Desc: not available
+URL: &lt;/pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0003.obj&gt;
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: gi01.diff
+Type: application/octet-stream
+Size: 1077 bytes
+Desc: not available
+URL: &lt;/pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0004.obj&gt;
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: gi02.diff
+Type: application/octet-stream
+Size: 1252 bytes
+Desc: not available
+URL: &lt;/pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0005.obj&gt;
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: gi03.diff
+Type: application/octet-stream
+Size: 891 bytes
+Desc: not available
+URL: &lt;/pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0006.obj&gt;
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: gi04.diff
+Type: application/octet-stream
+Size: 812 bytes
+Desc: not available
+URL: &lt;/pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0007.obj&gt;
+</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>