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 889AB158041 for ; Sat, 30 Mar 2024 17:13:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 31226E2A54; Sat, 30 Mar 2024 17:13:31 +0000 (UTC) Received: from s1.swsch.de (s1.swsch.de [IPv6:2a01:4f8:a0:8074::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D5A5CE2A36 for ; Sat, 30 Mar 2024 17:13:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xss.de; s=s1; h=Content-Type:MIME-Version:Reply-To:Message-Id:Date:Subject:To:From: Content-Transfer-Encoding:Sender:Cc; bh=IfkMtS/fybGdy+6gOtZrU7DHRVGZRXssMW/ZguxZ/LI=; b=P9S+ZUHgsVWsUBw0+ONa32ZHgb 2pK8YecPthkfoLVQ6YSujCjih5YtCAXoMM1nEEVTqBSbHCUt9DRaJ5XrbW3L7kaTTRtz6mKlOQddb vdybV5akRXfGTXquTlzZdEljuwZIGIU6DJSMch85D1j8Ambo/XPxFVYIp4AS5uexNofo=; Received: from [2003:d4:4703:db01:cde4:a7f4:5351:cd6b] by s1.swsch.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1rqcGn-000000002gI-0s73 for gentoo-dev@lists.gentoo.org; Sat, 30 Mar 2024 18:13:29 +0100 From: "Stefan Schmiedl" To: gentoo-dev@lists.gentoo.org Subject: Re[2]: [gentoo-dev] Current unavoidable use of xz utils in Gentoo Date: Sat, 30 Mar 2024 17:13:28 +0000 Message-Id: In-Reply-To: References: <20240329204315.3b29449b@Akita> <1671d927-55d5-6f01-2b54-b33981406945@gmail.com> User-Agent: eM_Client/9.2.2157.0 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: multipart/alternative; boundary="------=_MB99BFEC07-9974-4EC9-B864-A74F03D3E9DB" X-Archives-Salt: e161cdd2-0e7c-4005-b48a-e06f1b036969 X-Archives-Hash: 6e8b8bc43237dd130009a538aef1c269 --------=_MB99BFEC07-9974-4EC9-B864-A74F03D3E9DB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable ------ 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=C5=82 G=C3=B3rny 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 t= o >>> 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 lo= ad >> four times and add a lot of complexity to ebuilds, right? >> >> -- >> Best regards, >> Micha=C5=82 G=C3=B3rny >> > >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=20 xz-utils] to choose from" As long as the file format itself is not inherently messed up, the=20 archives could stay as .xz, only a "minimal" unxz (similar to unrar) would be=20 required to access the contents. Regards, s. --------=_MB99BFEC07-9974-4EC9-B864-A74F03D3E9DB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
------ Original Message ------
From "Eddie Chapman" <eddie@ehuk.= net>
Date 30.03.2024 16:17:19
Subject Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo=

Micha=C5=82 G=C3=B3rny wrote:
On Sat, 2024-03-30 at 14:57 +0000, Eddie Chapman = wrote:
=C2=A0
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 a= ble to continue to do so
without any friction whatsoever.
=C2=A0
So, you're basically saying we should go out of= our way, recompress all
distfiles using two alternative compression form= ats, increase mirror load
four times and add a lot of complexity to ebuild= s, right?
=C2=A0
--
Best regards,
Micha=C5=82 G=C3=B3rny
=C2=A0
=C2=A0
Yes that's a very good point, that was something= I was wondering in
weighing up both sides, what the costs would be p= ractically, as I don't
know the realities of running Gentoo infrastructu= re. And maybe the costs
is just too high of a price to pay.
=C2=A0
I wonder if increased use of git repos rather tha= n distributed tarballs
could be part of a solution to those issues, alth= ough 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 gi= t directory after clone
with compression. But yes granted then there is= even more ebuild
complexity.
=C2=A0
Huh ... I read you= r original message as=C2=A0

"wouldn't it be nice to have at least 2 alternative [implementa= tions of xz-utils]
to choose from"

= As long as the file format itself is not inherently messed up, the ar= chives
could = stay as .xz, only a "minimal" unxz (similar to unrar) would be required
to access the= contents.
Regards= ,
s.<= /div> --------=_MB99BFEC07-9974-4EC9-B864-A74F03D3E9DB--