[Mageia-dev] Meeting tonight

Thu Sep 15 11:26:41 CEST 2011

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