[Mageia-dev] Meeting tonight

[Stew Benedict]

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