Carl-Daniel Hailfinger wrote:
Hi,
some time ago, I invented Delta-RPMs to reduce the needed time and bandwidth for online updates. This was big leap ahead at that time. Right now I'm asking myself if there are other parts of the process which can be made more efficient.
Current state: 1) First add of an online update source needs 2 minutes and downloads all metadata 3 times. This is ~380 kb ATM. 2) There is no way to find out whether your update mirror is up to date. It may as well serve patches from years ago. 3) Updates for installed packages are downloaded as full RPMs. This throws us back to the dark times of 9.0 and before. 4) Installation of packages for which an update is available will fetch the full RPMs from the net instead of using the local installation source and Delta-RPMs from the net. 5) "Online Update Configuration" module in yast will not launch if you remove zen* and its dependencies (that includes suse_register). The icon should not appear if it doesn't work. 6) "Online Update Setup" module in yast will present you with an empty dialog if you remove zen* and dependencies. Well, at least you can click on "Back", "Abort" and "Finish" (all have the same effect). 7) "Online Update" module in yast will NOT tell you that no update source is configured and instead happily claim that no updates are available.
How to fix these issues: 1) Bug. Not yet annoying because only a few patches have been released. 2) By Design. Date of last change in update source could probably be displayed in the UI, but this still doesn't give you the ability to find out whether there was a more recent change. Suggestion: Get timestamp of last released update (and only that timestamp) from central location, e.g. by HTTP download of a signed timestamp.txt. 3) Bug. Marcus Meissner wrote this will be fixed. 4) Minor/Enhancement. The current state is MUCH better than everything we had before. Maybe make it configurable, but at least make sure beasts like OOo are not downloaded as full RPM from update sources if installation source is local and update source is remote. 5) Bug. Confusing, but can be understood by looking in y2log. 6) Bug. Same class as 5). 7) Bug. Arguably a security bug.
Any other issues you had with the update process? If so, please comment. Any other issues with network usage of package management in general? Tell me.
I'm off to feed bugzilla.
Strange pet you have :-) I understand that Linux is always under construction and one company can't wait until it reaches stable version, but with problems in installation and update area no one will profit. It looks so familiar, but not in Linux. -- Regards, Rajko.