Mailinglist Archive: opensuse-features (518 mails)

< Previous Next >
[openFATE 309561] Delta downloads of reposoitory metadata
  • From: fate_noreply@xxxxxxx
  • Date: Thu, 12 Aug 2010 23:23:10 +0200 (CEST)
  • Message-id: <feature-309561-4@xxxxxxxxxxxxxx>
Feature changed by: jpxviii jpxviii (jpxviii)
Feature #309561, revision 4
Title: Delta downloads of reposoitory metadata

Hackweek V: Unconfirmed
Priority
Requester: Important

+ openSUSE-11.4: Unconfirmed
+ Priority
+ Requester: Mandatory

Requested by: Michael Schröder (mlschroe)

Description:
We already use deltarpms do speed up downloading of rpms when doing an
update. Unfortunately, the repository metadata is also quite a chunk of
data which considerably slows down update speed.
The idea is to use a zsync like algorithm to fetch only the changed
parts of the metadata. The implementation will use libcurl's multi
interface to work with multiple connections in parallel.
Another benefit is that the code can replace the aria2c interface,
which does not fit well into the current code (different proxy handling
and the like).

Discussion:
#1: Jan Engelhardt (jengelh) (2010-06-02 12:41:45)
Say, if we were to (finally) use solv-style metadata instead of rpm-md,
wouldn't the problem reduce itself?
 
Also, if it were possible to have an aggregate metadata instead that
can reference multiple subrepositories, big repositories (like packman
and mine) could split theirs up into grouped repositories without
having to add extra .repo entries to /etc/zypp/repos.d.
E.g.
/multimedia/i586/MPlayer.rpm
/multimedia/i586/ffmpeg.rpm
/multimedia/repodata/*
/games/i586/trackball.rpm
/games/i586/...
/games/repodata/*
/repodata/aggregate.xml
 
Each group (multimedia, games) would have its own metadata, that is,
being a self-contained repository. And aggregate.xml containins then:
 
<link ref="multimedia/" />
<link ref="games/" />
 
So that when there is an update in games, only games's md needs to be
downloaded, instead of the big one.



--
openSUSE Feature:
https://features.opensuse.org/309561

< Previous Next >
This Thread
  • No further messages