Feature changed by: Oliver Kurz (okurz) Feature #303532, revision 37 Title: Reduce size of updates for openSUSE Factory Buildservice: Rejected by Lars Vogdt (lrupp) reject date: 2011-04-20 19:16:50 reject reason: We already reduce the size of Factory updates by using build compare. Milestone: 2.5 Priority Requester: Important Projectmanager: Important openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-06-06 09:06:29 reject reason: not really attached to a specific openSUSE version Priority Requester: Important Projectmanager: Important openSUSE-11.1: Rejected by Adrian Schröter (adriansuse) reject date: 2008-11-06 16:10:03 reject reason: This is a build service feature, but no distribution feature. Priority Requester: Important Projectmanager: Important Requested by: Michael Löffler (michl19) Partner organization: openSUSE.org Description: 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. References: packages: obs-server + Relations: + - idea for delta-rpm support in openSUSE Tumbleweed (url: + https://progress.opensuse.org/issues/10352) Discussion: #1: Stephan Kulow (coolo) (2008-03-27 16:48:43) 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. #2: Duncan Mac-Vicar (dmacvicar) (2008-04-22 13:28:56) 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. #3: Duncan Mac-Vicar (dmacvicar) (2008-05-26 17:09:31) 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. #7: Andreas Jaeger (a_jaeger) (2009-07-14 21:36:57) (reply to #3) What is the status of the Build Service side for this? #8: Adrian Schröter (adriansuse) (2009-09-15 16:42:11) (reply to #7) 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). #4: Gerald Pfeifer (geraldpfeifer) (2009-01-03 14:54:00) Opening this up for openSUSE.org. #5: Stephan Kulow (coolo) (2009-01-16 08:24:42) 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) #6: Piotrek Juzwiak (benderbendingrodriguez) (2009-06-17 17:29:42) 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. #9: Lars Vogdt (lrupp) (2009-10-01 12:33:06) (reply to #6) 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. #10: Stephan Kulow (coolo) (2009-10-01 13:03:18) (reply to #9) download.o.o will keep the old versions alive and the mirrors only get the latest. #11: Ralph Ulrich (ulenrich) (2009-10-01 14:56:11) Why not a more differentiated factory scheme like Debian: - unstable - testing (less frequently changes) Something similar is implemented now using factory snapshots ? -- openSUSE Feature: https://features.opensuse.org/303532