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 EBB77158041 for ; Sun, 31 Mar 2024 01:41:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 11D5AE2A78; Sun, 31 Mar 2024 01:41:18 +0000 (UTC) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 F0427E2A64 for ; Sun, 31 Mar 2024 01:41:16 +0000 (UTC) Received: by mail-vs1-xe2e.google.com with SMTP id ada2fe7eead31-47832f13a82so948188137.1 for ; Sat, 30 Mar 2024 18:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711849276; x=1712454076; darn=lists.gentoo.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=mhNaYJlNLwiomEH2Hrzr61HzqicwbaLRJqPO6ABLAfM=; b=jrLY6A0izC2t7CQbYQGACKE+i8qATZJp/isZ5/joigxtY21yiNhllleyc7W5x0izJi oz0XUhIjHVLIfM/r0qciENKyFl5s/9wlyH13vjhjIeylEDZl29RFHbcD8QKodPSEmV4r CCNoNMI4zripSj8XahlrAbYJd5V0Bshmq+u8qSVLiDvbUueZFEOvGmQd/RC0Bzr2uE1T Yn+tPxTxb2kWsBIY6Vk76WTGFxfR3GxUt5rcGKrNlFdT7Bo4qELbcCnDeLFCDg28xfhL 6yeco4F2xWy03Gy6xd/eTkbWiFQMCil6N/NyKwlTlkDXtCpCFtzc++bNV760f7rcD7IR 1mKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711849276; x=1712454076; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mhNaYJlNLwiomEH2Hrzr61HzqicwbaLRJqPO6ABLAfM=; b=YPWxq48NhcaTuFEyZopWto24H1n7zu+mgpp0yr0T675WMvibwZto5GoOPcPlrnJAjm v3tNTr298XgBW14NzrNtuJeb4IsPyKkGrFMetp05+npyqU9C3ofDAumeOKvkyjQ+/hK+ DYH8NIfVrOKyBCn1PfTQBfWBoSkqrUQQPei9UY63YzzsvR6emQYPotYi+D5xmUzdD3Tz 6cMzo4JVYnzT0NtnA22g4frprKo35H7lFF1XO1veYGodG6tUcRq3OT3mU6GLifMc5vY5 DlaaPCFLIs0MwR6Id5xwRwAJM33GCp1g4J+tTezHZbteooKetYMolvLHzxkdWek8Gxa7 4Svw== X-Gm-Message-State: AOJu0Yym9krSZc4NbxdUsSwXecC3VCRlEoKg1j0KgpOMUjLao3YT7Zp/ e2OlIef81mAM/Y21180jDIQ8ymEBKck2EfLBHB12dGoKxxqPEzWpMlbQ436OixHkODh4Ai3Ftwz QrXiFePlUREyW8K5rFgEs68wml7w2cB5o X-Google-Smtp-Source: AGHT+IHSf8IY5nc0cRVMvxVnfD5/KTxUTUvUG+GKHomPFIc7/ewt+gl67ZAI1O+08eZvVmVyGdwOMNjgvbJ44hk+u1E= X-Received: by 2002:a05:6102:34e:b0:478:411b:af01 with SMTP id e14-20020a056102034e00b00478411baf01mr4397926vsa.2.1711849276071; Sat, 30 Mar 2024 18:41:16 -0700 (PDT) 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 References: <20240329204315.3b29449b@Akita> <1671d927-55d5-6f01-2b54-b33981406945@gmail.com> <92c2c3fde2de811b483422909586076f.squirrel@ukinbox.ecrypt.net> In-Reply-To: <92c2c3fde2de811b483422909586076f.squirrel@ukinbox.ecrypt.net> From: Thomas Gall Date: Sat, 30 Mar 2024 20:41:05 -0500 Message-ID: Subject: Re: Re[2]: [gentoo-dev] Current unavoidable use of xz utils in Gentoo To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary="0000000000000266be0614eaf8fe" X-Archives-Salt: 414ffbe5-e35c-452b-861a-03b313131437 X-Archives-Hash: 09bcb60e747bbe93b2796941b5670192 --0000000000000266be0614eaf8fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A decompression implementation all in rust it would seem. https://github.com/gendx/lzma-rs On Sat, Mar 30, 2024 at 12:36=E2=80=AFPM Eddie Chapman wro= te: > 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=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 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=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 tarball= s > >> 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. > > > --0000000000000266be0614eaf8fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A decompression implementation all in rust it would seem.=




On Sat, Mar 30, 2024 at 12:36=E2=80=AFPM Edd= ie Chapman <eddie@ehuk.net> wro= te:
Stefan Schmiedl wrote:
> ------ Original Message ------
>
>> From "Eddie Chapman" <eddie@ehuk.net>
>>
> To ge= ntoo-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 to continue using and trusting xz-utils sh= ould be
>>>> able to continue to do so without any friction whatsoever.=
>>>
>>> So, you're basically saying we should go out of our way, r= ecompress
>>> all distfiles using two alternative compression formats, incre= ase
>>> mirror load 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 wonderi= ng 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 tar= balls
>>=C2=A0 could be part of a solution to those issues, although that c= ould 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 direc= tory
>> after clone with compression.=C2=A0 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 [implemen= tations 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 t= o 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.


--0000000000000266be0614eaf8fe--