From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sa-prd-fep-047.btinternet.com (mailomta22-sa.btinternet.com [213.120.69.28]) by sourceware.org (Postfix) with ESMTPS id EC4EE3858D37 for ; Sat, 22 Jan 2022 20:23:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EC4EE3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from sa-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.38.5]) by sa-prd-fep-047.btinternet.com with ESMTP id <20220122202340.NDVF16049.sa-prd-fep-047.btinternet.com@sa-prd-rgout-002.btmx-prd.synchronoss.net> for ; Sat, 22 Jan 2022 20:23:40 +0000 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 6139417C1235E57F X-Originating-IP: [81.129.146.209] X-OWM-Source-IP: 81.129.146.209 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvvddrvddvgddufeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepfedvveejueffvddtvdefteefjedvveefhffhgeegheffueetjefgkeevieekleegnecuffhomhgrihhnpehjughivghtvghrrdhnvghtpdhgihhthhhusgdrtghomhenucfkphepkedurdduvdelrddugeeirddvtdelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghloheplgduledvrdduieekrddurddutdefngdpihhnvghtpeekuddruddvledrudegiedrvddtledpmhgrihhlfhhrohhmpehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkpdhnsggprhgtphhtthhopedupdhrtghpthhtoheptgihghifihhnqdgrphhpshestgihghifihhnrdgtohhm X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.103] (81.129.146.209) by sa-prd-rgout-002.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 6139417C1235E57F for cygwin-apps@cygwin.com; Sat, 22 Jan 2022 20:23:40 +0000 Message-ID: <6ee3cda2-33b8-ccdc-ef24-f75a1d8ee046@dronecode.org.uk> Date: Sat, 22 Jan 2022 20:23:21 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: =?UTF-8?Q?Re=3a_Using_ZChunk_for_setup=e2=80=a6?= Content-Language: en-GB To: "cygwin-apps@cygwin.com" References: <87h7ad5fv6.fsf@Rainer.invalid> From: Jon Turney In-Reply-To: <87h7ad5fv6.fsf@Rainer.invalid> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3571.0 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2022 20:23:44 -0000 On 09/01/2022 11:05, Achim Gratz wrote: > > I've been experimenting with ZChunk with the idea of eventually using it > for setup: > > https://www.jdieter.net/posts/2018/05/31/what-is-zchunk/ > https://github.com/zchunk/zchunk > > The chunked ini file is ~10…15% larger than the original (after > compression). In order to minimize the overhead, I've re-arranged the > package entries to have one chunk for every source package. The actual > benefit is that the typical download size reduces to less than 5% of the > original. Two examples of much longer timespans between updates are > provided at the end, which would still download only around a third of > the original: > [...] > > WDYT? This seems like a nice thing to have. How would the signature be checked? Is it for the reconstructed full zchunk file? One slightly related issue which it would be good to address if possible when adding this is that rsync is only file-atomic, not repo-atomic, so we may get a compressed ini file and signature which don't match as they are different moments in time during an update. I think currently no-one notices this if it happens, as setup silently falls back to an older compression type, but it would be nice to stop generating those eventually.