[Mageia-dev] Meeting tonight

Thu Sep 15 12:36:40 CEST 2011

On 09/15/2011 05:26 AM, Thierry Vignaud wrote:
+> 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).
+What complicates things is:
+
+1) we're adding new packages to updates for the mga1 exception
+2) we're being quite loose with bumping versions for updates, apparently 
+patching is "too hard" for the new generation of packagers
+3) we're trying to chase being able to do an update from mdv-2010.2 and 
+whatever those people might have installed as they use updates/backports
+
+-- 
+Stew Benedict
+
+
+