[Mageia-dev] Trying to solve bug #2317 (was: Re: Meeting tonight)

Thu Sep 22 14:35:55 CEST 2011

Le jeudi 15 septembre 2011 16:12:11, Thierry Vignaud a écrit :
+[...]
+> Suggestions:
+> - investigating using the equivalent of --searchmedia
+
+That is an interesting option indeed.
+
+> - 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"
+
+This looks like a heavy solution (needs new ISOs, doesn't cover already 
+migrated systems, means that mdv packages that have no equivalent in mageia 
+are removed from the system), so it's not my preferred solution.
+
+> - patch perl-URPM so that foobar-X-Ymga is always newer than foobar-Z-Wmdv
+
+I'm sorry, but I don't understand what problems this third option would solve. 
+Can you explain to me (and maybe I'm not alone) ?
+
+> 
+> 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)
+
+I applied those 4 patches to rpmdrake and built a RPM that I installed on my 
+system, but I haven't seen a difference in behaviour. The msec update candidate 
+from updates_testing (updates_testing media have the update flag set on my 
+system) still can't be installed, with the following message:
+
+Sorry, the following package cannot be selected:
+- msec-0.80.10-2.2.mga1.i586 (due to unsatisfied sendmail)
+
+It apparently still doesn't use the /release media in MageiaUpdate, if I infer 
+correctly from the console logs :
+
+[root at localhost ~]# LC_ALL=C MageiaUpdate
+getting lock on urpmi
+using mirror ftp://distrib-
+coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/i586
+retrieved $MIRRORLIST media/core/updates media_info/MD5SUM
+comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core 
+Updates/MD5SUM
+medium "Core Updates" is up-to-date
+retrieved $MIRRORLIST media/core/updates_testing media_info/MD5SUM
+comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Core Updates 
+Testing/MD5SUM
+medium "Core Updates Testing" is up-to-date
+retrieved $MIRRORLIST media/nonfree/updates media_info/MD5SUM
+comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree 
+Updates/MD5SUM
+medium "Nonfree Updates" is up-to-date
+retrieved $MIRRORLIST media/nonfree/updates_testing media_info/MD5SUM
+comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Nonfree Updates 
+Testing/MD5SUM
+medium "Nonfree Updates Testing" is up-to-date
+retrieved $MIRRORLIST media/tainted/updates media_info/MD5SUM
+comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted 
+Updates/MD5SUM
+medium "Tainted Updates" is up-to-date
+retrieved $MIRRORLIST media/tainted/updates_testing media_info/MD5SUM
+comparing /var/cache/urpmi/partial/MD5SUM and /var/lib/urpmi/Tainted Updates 
+Testing/MD5SUM
+medium "Tainted Updates Testing" is up-to-date
+unlocking urpmi database
+getting lock on urpmi
+using mirror ftp://distrib-
+coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/1/i586
+examining synthesis file [/var/lib/urpmi/Core Updates/synthesis.hdlist.cz]
+examining synthesis file [/var/lib/urpmi/Core Updates 
+Testing/synthesis.hdlist.cz]
+examining synthesis file [/var/lib/urpmi/Nonfree Updates/synthesis.hdlist.cz]
+examining synthesis file [/var/lib/urpmi/Nonfree Updates 
+Testing/synthesis.hdlist.cz]
+examining synthesis file [/var/lib/urpmi/Tainted Updates/synthesis.hdlist.cz]
+examining synthesis file [/var/lib/urpmi/Tainted Updates 
+Testing/synthesis.hdlist.cz]
+
+[...] 
+> >> 1)  we know there will be cases where it won't work
+> >>      (see above those with the DVD media and not the full network
+> >>      media, some new dependencies won't be found on the DVD, ...).
+> >>      Multiply by those who have installed 32 DVD, 64 DVD, dual arch DVD,
+> >> ... There are lots of different scenarios to deal with ...
+> > 
+> > I think most of us are ready to ask users to add the full media set along
+> > with updates media.
+> 
+> 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.
+
+Yes, that is something we will have to decide independently of bug 2137 : do 
+we still want self-contained updates media in the future (when the mdv=>mga 
+transition problem will be gone) or not. I don't know, I see drawbacks in both 
+ways. 
+If the tools add the whole media set by default (removing the button that 
+proposes only updates media), and if we add proper warnings and helpers in the 
+right place (for example have MageiaUpdate and/or rpmdrake detect the lack of 
+activated release media and propose to add them, the way it does for update 
+media currently), we should cover much more than 50% of the end-users.
+
+Also, a message such as "Sorry, the following package cannot be selected:
+- msec-0.80.10-2.2.mga1.i586 (due to unsatisfied sendmail)" is much more 
+understandable when you *don't* have release media available on your system 
+than when you do. Especially when starting the update tool you already got a 
+message saying that you should activate the release media.
+
+So the main argument that I would keep in favor of copying dependencies to 
+updates media would be if we want to support the mirroring of updates media 
+only. But I'm not sure it is worth the extra work (although I may be wrong).
+
+[...]
+> 
+> > 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 ?
+> 
+> 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..
+
+Indeed. But those should understand the error message I hope (and if they 
+don't, well, *they* played with the skip list :) ).
+
+> >> Will you provides patches, test scenario and do the testing?
+> > 
+> > Patches, not sure. Test scenarios is doable, testing too.
+> 
+> The faillure of the proposed patch should be a scenario for regression
+> testing btw.
+
+Indeed.
+
+Best regards
+
+Samuel
+