Re: [opensuse] [RFC] Reducing Online Update Requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Burmeister wrote: [...] (big snip, just wanted to comment on one point) >> 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. > > I proposed this when 9.3 was recent, do not know what happened to it, since > the bug-reports from back then are not open. Note that this is not feasible because you can't just invent new files in repositories. The yast2 repository format certainly is under control and could be enhanced by such a file, but it's not that simple, there are quite a few 3rd party repositories out there as well. Also, YaST2 supports RPM-MD (aka yum) repositories since SUSE 10.0, and that format is a "standard" (more or less) and people use createrepo to generate RPM-MD metadata. createrepo doesn't know anything about a timestamp.txt and would have to be modified to do that - only for SUSE. That's not necessarily a good idea. The other option would be to retrieve the last modified timestamp of a file that's part of the already generated metadata (preferably one that changes with every metadata generation run ;)). For example: - - for RPM-MD: /repodata/filelists.xml.gz - - for yast2: /setup/descr/packages But that depends on the respective network protocol. It can be done with FTP. I don't know about HTTP, don't think it's possible. cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEbwIdr3NMWliFcXcRAtTqAJ4/GShMhxwPsc8JPGCuPS+saiAvEQCfVKZy qArcoFY8kwh3QhPP3tFsHM4= =BeD0 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] [RFC] Reducing Online Update Requirements
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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] [RFC] Reducing Online Update Requirements
Hi! Am Freitag, 19. Mai 2006 21:04 schrieb Carl-Daniel Hailfinger: > Current state: > 1) First add of an online update source needs 2 minutes and >downloads all metadata 3 times. This is ~380 kb ATM. Have you tried the "update" from the RMB-menu on the systray-icon? I have six catalogues: inst-source, updates, packman, oc2pus, guru, supplementary. On my 1.4GHz with 512MB RAM it takes 5 minutes with one of update-status or parse-metadata running at > 90% CPU usage. That does not sound very efficient. > 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. I filed a bug on this. https://bugzilla.novell.com/show_bug.cgi?id=173373 Apparently it is not possible at the moment. The sad thing is, that this fix would not reach people, because one would have to add the update-source in first place. > How to fix these issues: > 1) Bug. Not yet annoying because only a few patches have been >released. I find it very annoying that the new tools seem to take > 90% of CPU and take longer for adding an installation source, deleting one, updating them and so on. Most of these processes even lack a progress-bar, i.e. the user does not know whether the app hangs or is progressing. > 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. I proposed this when 9.3 was recent, do not know what happened to it, since the bug-reports from back then are not open. > 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. - Too high CPU usage for too long. - It is no longer possible to "refresh", i.e. not "update" a package, anymore. The bug was marked as WONTFIX. https://bugzilla.novell.com/show_bug.cgi?id=173369 - The new online-update-window does not refresh while installing a package, so if it is a large one, the window will go blank, if one moves it and become unresponsive. - I think that in the new update-tool there is no progress-bar for the download-process, it just advances on a "package installed basis". - The update-server is picked automatically, i.e. the user does not get offered a list to choose from, which I think is bad, as I got a very slow update-server which is not even close to where I live. Sven - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] [RFC] Reducing Online Update Requirements
Carl-Daniel Hailfinger wrote: 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. with the growing size of mass storage, keeping all the rpms on a hard drive is no longer ridiculous, so this point is important. one could think of downloading all the up(grade/date?) in the background with low priority jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] [RFC] Reducing Online Update Requirements
Michael Schroeder wrote: > On Fri, May 19, 2006 at 09:04:20PM +0200, Carl-Daniel Hailfinger wrote: >> >> some time ago, I invented Delta-RPMs to reduce the needed time >> and bandwidth for online updates. > > Hey, don't write such things. Your scheme had nothing to do with > the ways deltarpms work. Current Delta-RPMs are indeed very different from what I invented back then. You changed the diffing algorithm from xdelta to bsdiff, added support for deltas-against-installed and changed the format from delta archive to rpm package, rewrote the whole thing from scratch. Probably a few other changes I forgot. Don't understand me wrong, I like the way Delta-RPMs are now. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] [RFC] Reducing Online Update Requirements
On Fri, May 19, 2006 at 09:04:20PM +0200, Carl-Daniel Hailfinger wrote:
> Hi,
>
> some time ago, I invented Delta-RPMs to reduce the needed time
> and bandwidth for online updates.
Hey, don't write such things. Your scheme had nothing to do with
the ways deltarpms work.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse] [RFC] Reducing Online Update Requirements
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. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
