Mailinglist Archive: opensuse-features (208 mails)
| < Previous | Next > |
[openFATE 303532] Reduce size of updates for openSUSE Factory
- From: fate_noreply@xxxxxxx
- Date: Wed, 20 Apr 2011 19:23:19 +0200 (CEST)
- Message-id: <feature-303532-36@keeper.suse.de>
Feature changed by: Lars Vogdt (lrupp)
Feature #303532, revision 36
Title: Reduce size of updates for openSUSE Factory
- Buildservice: Evaluation by engineering manager
+ 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)
Product Manager: (Novell)
Project Manager: (Novell)
Engineering Manager: (Novell)
Technical Contact: (Novell)
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
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
Feature #303532, revision 36
Title: Reduce size of updates for openSUSE Factory
- Buildservice: Evaluation by engineering manager
+ 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)
Product Manager: (Novell)
Project Manager: (Novell)
Engineering Manager: (Novell)
Technical Contact: (Novell)
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
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
| < Previous | Next > |