[Mageia-dev] Meeting tonight

[Thierry Vignaud]

On 14 September 2011 17:50, Samuel Verschelde <stormi at laposte.net> wrote:
> I don't know if it's the right meeting for it, but I would like us to talk
> again about bug 2317 https://bugs.mageia.org/show_bug.cgi?id=2317 that blocks
> updates
> We tried to previously chosen solution "link from Release to Updates", but we
> run into dependency nightmares such as in the end the solution would almost
> lead to copy the whole Release media into Updates.
>
> Without proof of the contrary,

what?
No it's not and I've already explained many times.
See below

> I tend to think that fixing MageiaUpdate would
> be a lot less work than the workaround we are trying to use which :
> - still needs work from the sysadmins
> - gives a lot of work to QA, that would be better used for testing the updates
> - forces us to link a lot of packages if we really want to make sure the
> update never fails

For now, we are in the same configuration as @ mdv:
the updates must be self host, if they add new
requires, these must be added to the repository to update.

This was decided a long time ago after thinking

Some people have the media networks, ie all packages
can be fetched.
Others will have only DVD media and thus only have a subset
of  packages.
Other disable certain media.
Other activate some other media (backports).
Some will have non-free and/or tainted enabled, some won't.
Ie there is no guarantee that a packet with new requires
can be updated on all machines as end users will have
a variety of packages subset.

For almost 10 years MandrivaUpdate == "urpmi --update"
and not "urpmi --auto-select"

I think that for the already released mga1 we should stick
to the known good old working method, the MDV's one,
rather than inventing a new quick & dirty thing quickly whom we'll
find subtle bugs along the incoming month

Some suggested removing the --update flag that MgaUpdate
"gives" to urpmi.

I think most of them ignore what kind of problems that would bring,
they haven't made any tests at all:

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

2) what's more, its not the time to do so, X months after the release

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

4) that means that we must also update mgaonline to change the way
     it computes if there any available updates (so that it
     doesn't reject/ignore  updates with missing Requires that can
     be resolved from */release

5) That means mgaapplet too will use quite a lot more time in
     order to compute if there any updates

 6) That means mgaaplet will consume more RAM when
   it checks the updates (more exactly the son process it
   forks)
   however people are already complaining about RAM usage
   in mgapapplet

7) rpmdrake behavior may change in unforeseen ways
    (because a a shared algorithm will changes)

8) Fred Lepied, Frederic Crozat & Warly have removed quite
   a lot of code everywhere since that policy went years (nearly
   a decade ago)
   that means there're a lot of tools that need potential patching
   (urpmi, rpmdrake, mgaonline, ...)
    for eg: checking for missing media, ...

In short, it's quite a lot more work and quite a lot more risky than
"just" not using the --update "flag" as some think.
They only see that it will be less work for them (the
work previously done by mdv's secteam for years, that is check
for new introduced requires and if yes add them to the update media)
It can just blow up in quite a lot of places:
- Updates that'll work for some and not for others depending
  on which media are enabled
- slower Mgaupdate
- Mgaupdate consuming more RAM
- slower Mgaapplet
- Mgaapplet consuming more RAM

IMHO it's obviously too risky to do such a major change and I failed
to see why we cannot work the mdv way.

For the _next_ release, we can test & try to use --media and look if:
performance doesn't drop too much
But we'll still have the same issues:
- Disparate media (various DVDs flavour vs network, ...)
- Performance: the fact that one can have quite a lot media:
 (3 (or 6 on biarch) updates media vs 9 (or 18 on biarch) media [1]
  even 15 or 30 (biarch) media for those who activate
  backport ledia [2].
- algorithm consistency: it must work for those who enable backports
  and those who don't, for those who enables tainted/non-free but not
  non-free/tainted , ....

This must be thought about.
Will you?
Will you provides patches, test scenario and do the testing?

my 2 cents

[1] 3 (release / testing / update) x 3 (core / non-free / tainted)
[2] 5 (release / testing / update / backport / backport_testing) x 3
(Core / non-free / tainted)

> What I would like is a firm and courageous decision

no comment...

> (we already talked a lot of
> this issue without much progress until now) that we set a date (soon) before
> which this problem will be completely solved, whatever the way.
>
> We really would like to have this issue solved and allow to concentrate on
> other important stuff (such as security updates for example).