[Mageia-dev] Meeting tonight

Thierry Vignaud thierry.vignaud at gmail.com
Thu Sep 15 16:12:11 CEST 2011


On 15 September 2011 12:48, Samuel Verschelde <stormi at laposte.net> wrote:
> 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 !

OK.

> See Dave's recent mail
> about bug 2317 that explains that in more details and gives the possible
> solutions to this situation.

Note that his patch is broken as reported by testers...
"the patch (...) suggested some updates from Backports Testing, even though
the repository was not enabled"

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 "urpmi --auto-select --update" into:
 "urpmi --auto-select --media='*/backports'"

> I would be interested (really) by your opinion
> about the solution to use among those he suggests,

see above

> or even another one.

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"
- 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 & 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()
& 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.

> 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)

wrongdoing...

>> 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.

> 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..

>> 2) what's more, its not the time to do so, X months after the release
>
> 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.

Sorry AFAIC after the release is too late by definition

>> 3) MgaUpdate will be _much_ slower (compare the startup time
>>     of rpmdrake vs MgaUpdate) because all synthesis
>>    have to be parsed, then we need to compute / verify a far greater
>>    number of potential updates ... (and it's _not_ O(n))
>>    just look at how much faster to start is mgaupdate vs rpmdrake)
>>   It will also consume a lot more RAM
>
> 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.


>> 7) rpmdrake behavior may change in unforeseen ways
>>     (because a a shared algorithm will changes)
>
> This one I can't tell, I don't know what shared algorithm you are talking
> about.

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 "I don't know" is exactly why
I'm warning from the beginning

>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r1.diff
Type: application/octet-stream
Size: 981 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r2.diff
Type: application/octet-stream
Size: 666 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r3.diff
Type: application/octet-stream
Size: 708 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r4.diff
Type: application/octet-stream
Size: 951 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gi01.diff
Type: application/octet-stream
Size: 1077 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gi02.diff
Type: application/octet-stream
Size: 1252 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gi03.diff
Type: application/octet-stream
Size: 891 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gi04.diff
Type: application/octet-stream
Size: 812 bytes
Desc: not available
URL: </pipermail/mageia-dev/attachments/20110915/e36848de/attachment-0007.obj>


More information about the Mageia-dev mailing list