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

[Samuel Verschelde]

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