| Summary: | having a WS providing the minimal package versions needed for live upgrade | ||
|---|---|---|---|
| Product: | Websites | Reporter: | Thierry Vignaud <thierry.vignaud> |
| Component: | mirrors.mageia.org | Assignee: | Sysadmin Team <sysadmin-bugs> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, filip.komar, rdalverny, sysadmin-bugs |
| Version: | trunk | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
|
Description
Thierry Vignaud
2012-03-25 13:17:43 CEST
The mgaapplet program already checks to see if there are any updates available, and doesn't present the option to upgrade to the new distro, unless all packages are up-to-date. I'm just restoring the mageia 1 install I'm using for the test of 5066, and will test the patch to gurpmi shortly. CC:
(none) =>
davidwhodgins Dave, I am the on who wrote mgaaplet in its current form, especially the part computing updates. I maintains it since 2006. So I know pretty well what it does. There're many ways it won't work: mgaaplet won't know if your update media are obsolete b/c your mirror don't work anymore. mgaaplet will accept having any media (core/release or your local repo for some perl package) tagged as update and not having any official updates. mgaaplet would accept starting live upgrade to mga N+1 if you applied all updates but sadly the mirror you're using doesn't sync often enough, meaning your machine missed a needed update. mgaaplet will miss updates if you trick /etc/urpmi/skip.list So yes, there're tons of way mgaaplet can start a live upgrade whereas we know it won't work In the old days, it was relying on a web server to compute the updates needed for the machine, which was unreliable, not knowing about urpmi algorithms, local urpmi config, ... resulting in starting up MxxOnline which would show no updates, or different updates, ... I made it using urpmi locally, which was a good move and makes it quite a lot more reliable. But it can still be improved by still using a web server to know that we miss some important updates. I made it compute updates locally instead of relying on a unreliable web server Sorry. Thanks for clarifying why and what things should be changed. I should pay more attention to who is posting a bug report, rather then just reading/replying to the contents. (In reply to comment #0) > It would be either a WS or simply a text file as for mirrors list or as for > version list. Who would maintain those files? CC:
(none) =>
rdalverny The urpmi/rpmdrake/mgaonline maintainer, aka me We already use releases.mageia.org/api/a/i586 (and relatives) to publish the possibility of an upgrade. We could use releases.mageia.org/api/a/1/upgrade_needs to list the needed packages? Why not. Ok, committed in SVN (under web/releases) and available at http://releases.mageia.org/api/a/1/upgrade_needs . Thierry is there anything left that needs to be done? It seems to me that we can close this one now that we have a WS. CC:
(none) =>
filip.komar |