Home_greyopenFATE - openSUSE feature tracking > #303532
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Reduce size of updates for openSUSE Factory

Feature state

Rejected Information
Rejected Information
Rejected Information


Each update currently is around 2GB which is already much for broadband bandwith. For user with less bandwith it's by and large impossible to use Factory. Goal is to reduce size of updates and stay with frequent updates to offer latest software to the user. As we want more people using Factory it's usage needs to be conveniant.



packages: obs-server


icons/user_comment.png S. K. wrote: (10 years ago)

According to discussions with Rudi and mls, the delta setup on dist need to be changed to also contain the rpm header and the deltas need to be indexed in a way that zypp will see them.

So we can still use drpmsync for internal distribution and put the deltas only in instsource for mirrors.

icons/user_comment.png D. M. wrote: (10 years ago)

This will happen automatically once the remaining parts of libzypp deltarpm handling are finished. We only need to agree on the format. I will propose something today.

icons/user_comment.png D. M. wrote: (10 years ago)

ZYpp side is done.

The only thing that needs to be done is to generate the deltarpm metadata in factory. I will post link to documentation and examples shortly.

icons/user_comment.png A. J. wrote: (9 years ago)

What is the status of the Build Service side for this?

icons/user_comment.png A. S. wrote: (9 years ago)

Partly implemented, the build-compare support exists, delta generation support is currently out of scope (if done on build host, it would need adaptions in backend parts. If done on extra(mirror) host, it would need to resign content, which breaks security concepts).

icons/user_comment.png G. P. wrote: (9 years ago)

Opening this up for openSUSE.org.

icons/user_comment.png S. K. wrote: (9 years ago)

ok, we discussed this a bit further. We plan to throw away builds that are equal to the previous build and publish deltas generated by the build clients if they are not equal.

If a build is equal is to be defined, for now it's a shell script that checks various properties - and works acceptable for now.

I rebuild a good portion of 11.1 without further changes and get 7345 binary rpms (including all subpackages). 5666 are considered equal by my current script (based on work by Michael Matz).

And many of other packages are possible to fix, so they are equal too. So this gives for uneffected rebuilds a huge reduction of updates.

The kernels and kmps are currently seen as !equal after an uneffected rebuild as they put the %release (rebuild counter) in many places. Not sure how much the script should work around such cases.

But even for those the download size would reduce:
kernel-default.i586 (with base and extra): 25.7MB to download
deltas of it: 6.7MB (I think the kernel puts a lot of "rebuild on" info in the code)

icons/user_comment.png P. J. wrote: (9 years ago)

As an addition to that it would be great if the older package would stay until the second rebuild so that if something breaks we could go back to the previous version and report that something's wrong with the new one.

icons/user_comment.png L. V. wrote: (9 years ago)

Having backups is always a good idea. But as we've just limited space (internally and on our mirrors) I don't think that we can implement this.

icons/user_comment.png S. K. wrote: (9 years ago)

download.o.o will keep the old versions alive and the mirrors only get the latest.

icons/user_comment.png R. U. wrote: (9 years ago)

Why not a more differentiated factory scheme like Debian:

- unstable

- testing (less frequently changes)

Something similar is implemented now using factory snapshots ?

Last change: 16 months ago
Loading tags...
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint