Mailinglist Archive: opensuse (5130 mails)

< Previous Next >
Re: [opensuse] [RFC] Reducing Online Update Requirements
  • From: Rajko M <rmatov101@xxxxxxxxxxx>
  • Date: Sat, 20 May 2006 06:11:35 -0500
  • Message-id: <446EF967.80903@xxxxxxxxxxx>
Carl-Daniel Hailfinger wrote:

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
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.


< Previous Next >