From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 20EE8158041 for ; Sat, 30 Mar 2024 17:36:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 170D9E2A64; Sat, 30 Mar 2024 17:36:22 +0000 (UTC) Received: from james.steelbluetech.co.uk (james.steelbluetech.co.uk [78.40.151.100]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AB594E2A52 for ; Sat, 30 Mar 2024 17:36:21 +0000 (UTC) Received: from ukinbox.ecrypt.net (hq2.ehuk.net [10.0.10.2]) by james.steelbluetech.co.uk (Postfix) with ESMTP id 10B90BFC18 for ; Sat, 30 Mar 2024 17:36:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.10.3 james.steelbluetech.co.uk 10B90BFC18 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ehuk.net; s=default; t=1711820180; bh=GC2PfS2yrdXkwKls6+czUpg4hDagO4u7FiKmNwq9pdM=; h=In-Reply-To:References:Date:Subject:From:To:Reply-To:From; b=EgU/zUemyyeDGK6Wda11eSXhRbmX6gfsjOsCZ4wOEzBtJTFkkAfCdNTsIWJwtmUR0 uwdftqhUz9NiAxMt1AvSDNLReW6T0SGe+Hsl1cQwQbCQePWMX2hiNhyr245tec1MFj 3V0vsZ6gEsyiwx7FjdPZbHt4PF8ZknVwP1Nbs7s/HTzGOsYBJBYcwKn2hTbDHkGiE5 schPMlV+VrCz8pkE0SDFsCMYU6yYgLTplJiKEDCvcWYMoMXwoUTDT9cpGwK2ayJYLo dIRGRyC8hS3ULS3eyAcCoSnizcoxSPUGhRPWUCW5eg5mLbn2tKfEcFcL/ENklQqDol DyufMklFWXUzw== Message-ID: <92c2c3fde2de811b483422909586076f.squirrel@ukinbox.ecrypt.net> In-Reply-To: References: <20240329204315.3b29449b@Akita> <1671d927-55d5-6f01-2b54-b33981406945@gmail.com> Date: Sat, 30 Mar 2024 17:36:20 -0000 Subject: Re: Re[2]: [gentoo-dev] Current unavoidable use of xz utils in Gentoo From: "Eddie Chapman" To: gentoo-dev@lists.gentoo.org User-Agent: SquirrelMail/1.5.2 [SVN] Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang X-Archives-Salt: 43143c02-18e6-49cf-9a64-82dc121a6046 X-Archives-Hash: ef866b4b1466d4d2195cf0be87bd53bb Stefan Schmiedl wrote: > ------ Original Message ------ > >> From "Eddie Chapman" >> > To gentoo-dev@lists.gentoo.org > Date 30.03.2024 16:17:19 > Subject Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo > >> Michał Górny wrote: >> >>> On Sat, 2024-03-30 at 14:57 +0000, Eddie Chapman wrote: >>> >>> >>>> Note, I'm not advocating ripping xz-utils out of tree, all I'm >>>> saying is wouldn't it be nice if there were at least 2 alternatives >>>> to choose from? That doesn't have to be disruptive in any way, >>>> people who wish to continue using and trusting xz-utils should be >>>> able to continue to do so without any friction whatsoever. >>> >>> So, you're basically saying we should go out of our way, recompress >>> all distfiles using two alternative compression formats, increase >>> mirror load four times and add a lot of complexity to ebuilds, right? >>> >>> -- >>> Best regards, >>> Michał Górny >> >> Yes that's a very good point, that was something I was wondering in >> weighing up both sides, what the costs would be practically, as I don't >> know the realities of running Gentoo infrastructure. And maybe the >> costs is just too high of a price to pay. >> >> I wonder if increased use of git repos rather than distributed tarballs >> could be part of a solution to those issues, although that could put >> quite a storage burden on every user. Unless they were all shallow git >> pulls and the user could optionally choose to tar up the git directory >> after clone with compression. But yes granted then there is even more >> ebuild complexity. >> > Huh ... I read your original message as > > "wouldn't it be nice to have at least 2 alternative [implementations of > xz-utils] to choose from" > > As long as the file format itself is not inherently messed up, the > archives could stay as .xz, only a "minimal" unxz (similar to unrar) would > be required to access the contents. > > Regards, > s. I see, no, I originally meant to have two compression/decompression formats; LZMA (xz) and another. But yes the way you understood it is interesting. Initially I dismissed this idea as would take too long for a new tool to reach stability. But yes what you suggest is it could be a very simple implementation that only does decompression so perhaps more realistically achievable. Still a tall order. I wonder if any general purpose languages (python, perl, etc) have developed their own built in LZMA decompression implementation? I doubt it, would have thought they'd just link against liblzma.so and not re-invent the wheel.