On 09/15/2011 05:26 AM, Thierry Vignaud wrote:
On 14 September 2011 17:50, Samuel Verschelde<[email protected]> 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
