[New: openFATE 309088] zsync support for update channel refresh
Feature added by: Dirk Mueller (dirkmueller) Feature #309088, revision 1 Title: zsync support for update channel refresh openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Dirk Mueller (dirkmueller) Partner organization: openSUSE.org Description: For every released maintenance update, the repodata/primary.xml.gz file grows by a bit (depending on the number of dependencies etc for every released package). To smoothen updater-experience and reduce the amount of data that has to be download for an update-repo refresh, the diff of the file should be downloaded by using zsync. In addition the repo-channel generation script has to run zsyncmake and gzip --rsyncable. Business case (Partner benefit): openSUSE.org: With openSUSE 11.2, the primary.xml.gz size grows by 1.1MB for every released kernel, and currently the file has to be downloaded completely upon every change (due to xml.gz compression). -- openSUSE Feature: https://features.opensuse.org/309088
Feature changed by: Michal Marek (michal-m) Feature #309088, revision 5 Title: zsync support for update channel refresh openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Dirk Mueller (dirkmueller) Partner organization: openSUSE.org Description: For every released maintenance update, the repodata/primary.xml.gz file grows by a bit (depending on the number of dependencies etc for every released package). To smoothen updater-experience and reduce the amount of data that has to be download for an update-repo refresh, the diff of the file should be downloaded by using zsync. In addition the repo-channel generation script has to run zsyncmake and gzip --rsyncable. - - Business case (Partner benefit): openSUSE.org: With openSUSE 11.2, the primary.xml.gz size grows by 1.1 MB for every released kernel, and currently the file has to be downloaded completely upon every change (due to xml.gz compression). + Discussion: + #1: Michal Marek (michal-m) (2010-03-01 12:27:41) + Another option would be to rotate the primary.xml file and let the zypp + parser trivially concatenate it. E.g. let createrepo sort the packages + by their build time (*), start with primary.xml.0 and when the output + exceeds a given threshold, continue with primary.xml.1, and so on. That + would give us similar incremental downloads without changing the + downloader code (and exposing bugs in curl/aria2c/proxies and other + fun). + (*) The sort order would reshuffle if an older package would be + approved later than a newer package, but that would hopefully not + happen too often and not affect the whole list. -- openSUSE Feature: https://features.opensuse.org/309088
Feature changed by: Michal Marek (michal-m) Feature #309088, revision 6 Title: zsync support for update channel refresh - openSUSE-11.3: Unconfirmed + openSUSE-11.3: Rejected by (michal-m) + reject date: 2010-10-08 14:20:39 + reject reason: Not done for 11.3, implemented as 309561 for 11.4 Priority Requester: Important Requested by: Dirk Mueller (dirkmueller) Partner organization: openSUSE.org Description: For every released maintenance update, the repodata/primary.xml.gz file grows by a bit (depending on the number of dependencies etc for every released package). To smoothen updater-experience and reduce the amount of data that has to be download for an update-repo refresh, the diff of the file should be downloaded by using zsync. In addition the repo-channel generation script has to run zsyncmake and gzip --rsyncable. Business case (Partner benefit): openSUSE.org: With openSUSE 11.2, the primary.xml.gz size grows by 1.1 MB for every released kernel, and currently the file has to be downloaded completely upon every change (due to xml.gz compression). Discussion: #1: Michal Marek (michal-m) (2010-03-01 12:27:41) Another option would be to rotate the primary.xml file and let the zypp parser trivially concatenate it. E.g. let createrepo sort the packages by their build time (*), start with primary.xml.0 and when the output exceeds a given threshold, continue with primary.xml.1, and so on. That would give us similar incremental downloads without changing the downloader code (and exposing bugs in curl/aria2c/proxies and other fun). (*) The sort order would reshuffle if an older package would be approved later than a newer package, but that would hopefully not happen too often and not affect the whole list. -- openSUSE Feature: https://features.opensuse.org/309088
Feature changed by: Jose Ricardo De Leon Solis (derhundchen) Feature #309088, revision 7 Title: zsync support for update channel refresh openSUSE-11.3: Rejected by (michal-m) reject date: 2010-10-08 14:20:39 reject reason: Not done for 11.3, implemented as 309561 for 11.4 Priority Requester: Important Requested by: Dirk Mueller (dirkmueller) Partner organization: openSUSE.org Description: For every released maintenance update, the repodata/primary.xml.gz file grows by a bit (depending on the number of dependencies etc for every released package). To smoothen updater-experience and reduce the amount of data that has to be download for an update-repo refresh, the diff of the file should be downloaded by using zsync. In addition the repo-channel generation script has to run zsyncmake and gzip --rsyncable. Business case (Partner benefit): openSUSE.org: With openSUSE 11.2, the primary.xml.gz size grows by 1.1 MB for every released kernel, and currently the file has to be downloaded completely upon every change (due to xml.gz compression). Discussion: #1: Michal Marek (michal-m) (2010-03-01 12:27:41) Another option would be to rotate the primary.xml file and let the zypp parser trivially concatenate it. E.g. let createrepo sort the packages by their build time (*), start with primary.xml.0 and when the output exceeds a given threshold, continue with primary.xml.1, and so on. That would give us similar incremental downloads without changing the downloader code (and exposing bugs in curl/aria2c/proxies and other fun). (*) The sort order would reshuffle if an older package would be approved later than a newer package, but that would hopefully not happen too often and not affect the whole list. + #2: Jose Ricardo De Leon Solis (derhundchen) (2010-10-10 07:25:18) + Somebody should mark this feature as done since feature #309561 is done + and is similar to this feature. -- openSUSE Feature: https://features.opensuse.org/309088
Feature changed by: Dirk Mueller (dirkmueller) Feature #309088, revision 8 Title: zsync support for update channel refresh openSUSE-11.3: Rejected by (michal-m) reject date: 2010-10-08 14:20:39 reject reason: Not done for 11.3, implemented as 309561 for 11.4 Priority Requester: Important + openSUSE-11.4: Duplicate of #309561 + Priority + Requester: Important Requested by: Dirk Mueller (dirkmueller) Partner organization: openSUSE.org Description: For every released maintenance update, the repodata/primary.xml.gz file grows by a bit (depending on the number of dependencies etc for every released package). To smoothen updater-experience and reduce the amount of data that has to be download for an update-repo refresh, the diff of the file should be downloaded by using zsync. In addition the repo-channel generation script has to run zsyncmake and gzip --rsyncable. + Relations: + - feature/duplicate: 309561 Business case (Partner benefit): openSUSE.org: With openSUSE 11.2, the primary.xml.gz size grows by 1.1 MB for every released kernel, and currently the file has to be downloaded completely upon every change (due to xml.gz compression). Discussion: #1: Michal Marek (michal-m) (2010-03-01 12:27:41) Another option would be to rotate the primary.xml file and let the zypp parser trivially concatenate it. E.g. let createrepo sort the packages by their build time (*), start with primary.xml.0 and when the output exceeds a given threshold, continue with primary.xml.1, and so on. That would give us similar incremental downloads without changing the downloader code (and exposing bugs in curl/aria2c/proxies and other fun). (*) The sort order would reshuffle if an older package would be approved later than a newer package, but that would hopefully not happen too often and not affect the whole list. #2: Jose Ricardo De Leon Solis (derhundchen) (2010-10-10 07:25:18) Somebody should mark this feature as done since feature #309561 is done and is similar to this feature. -- openSUSE Feature: https://features.opensuse.org/309088
Feature changed by: Dirk Mueller (dirkmueller) Feature #309088, revision 9 Title: zsync support for update channel refresh openSUSE-11.3: Rejected by (michal-m) reject date: 2010-10-08 14:20:39 reject reason: Not done for 11.3, implemented as 309561 for 11.4 Priority Requester: Important openSUSE-11.4: Duplicate of #309561 Priority Requester: Important Requested by: Dirk Mueller (dirkmueller) Partner organization: openSUSE.org Description: For every released maintenance update, the repodata/primary.xml.gz file grows by a bit (depending on the number of dependencies etc for every released package). To smoothen updater-experience and reduce the amount of data that has to be download for an update-repo refresh, the diff of the file should be downloaded by using zsync. In addition the repo-channel generation script has to run zsyncmake and gzip --rsyncable. Relations: - feature/duplicate: 309561 Business case (Partner benefit): openSUSE.org: With openSUSE 11.2, the primary.xml.gz size grows by 1.1 MB for every released kernel, and currently the file has to be downloaded completely upon every change (due to xml.gz compression). Discussion: #1: Michal Marek (michal-m) (2010-03-01 12:27:41) Another option would be to rotate the primary.xml file and let the zypp parser trivially concatenate it. E.g. let createrepo sort the packages by their build time (*), start with primary.xml.0 and when the output exceeds a given threshold, continue with primary.xml.1, and so on. That would give us similar incremental downloads without changing the downloader code (and exposing bugs in curl/aria2c/proxies and other fun). (*) The sort order would reshuffle if an older package would be approved later than a newer package, but that would hopefully not happen too often and not affect the whole list. #2: Jose Ricardo De Leon Solis (derhundchen) (2010-10-10 07:25:18) Somebody should mark this feature as done since feature #309561 is done and is similar to this feature. + #3: Dirk Mueller (dirkmueller) (2010-10-11 09:58:55) (reply to #2) + done. -- openSUSE Feature: https://features.opensuse.org/309088
Feature changed by: Matthias Eckermann (mge1512) Feature #309088, revision 10 Title: zsync support for update channel refresh - openSUSE-11.3: Rejected by (michal-m) + openSUSE-11.3: Rejected by Michal Marek (michal-m) reject date: 2010-10-08 14:20:39 reject reason: Not done for 11.3, implemented as 309561 for 11.4 Priority Requester: Important openSUSE-11.4: Duplicate of #309561 + Master status: Done Priority Requester: Important Requested by: Dirk Mueller (dirkmueller) Partner organization: openSUSE.org Description: For every released maintenance update, the repodata/primary.xml.gz file grows by a bit (depending on the number of dependencies etc for every released package). To smoothen updater-experience and reduce the amount of data that has to be download for an update-repo refresh, the diff of the file should be downloaded by using zsync. In addition the repo-channel generation script has to run zsyncmake and gzip --rsyncable. Relations: - feature/duplicate: 309561 Business case (Partner benefit): openSUSE.org: With openSUSE 11.2, the primary.xml.gz size grows by 1.1 MB for every released kernel, and currently the file has to be downloaded completely upon every change (due to xml.gz compression). Discussion: #1: Michal Marek (michal-m) (2010-03-01 12:27:41) Another option would be to rotate the primary.xml file and let the zypp parser trivially concatenate it. E.g. let createrepo sort the packages by their build time (*), start with primary.xml.0 and when the output exceeds a given threshold, continue with primary.xml.1, and so on. That would give us similar incremental downloads without changing the downloader code (and exposing bugs in curl/aria2c/proxies and other fun). (*) The sort order would reshuffle if an older package would be approved later than a newer package, but that would hopefully not happen too often and not affect the whole list. #2: Jose Ricardo De Leon Solis (derhundchen) (2010-10-10 07:25:18) Somebody should mark this feature as done since feature #309561 is done and is similar to this feature. #3: Dirk Mueller (dirkmueller) (2010-10-11 09:58:55) (reply to #2) done. -- openSUSE Feature: https://features.opensuse.org/309088
participants (1)
-
fate_noreply@suse.de