Stefan Schmiedl wrote:

------ Original Message ------

From "Eddie Chapman" <eddie@ehuk.net>

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

------ Original Message ------
From "Eddie Chapman" <eddie@ehuk.net>
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.
<html><head>

<style id="signatureStyle" type="text/css"><!--#xe4a7c8ebf77c4c1 #xe61c1979f7dd4eaeb9a72a2370c0e757 p
{margin: 0px;}
#xe4a7c8ebf77c4c1 #xe61c1979f7dd4eaeb9a72a2370c0e757
{font-family: "Segoe UI"; font-size: 12pt;}
#xe4a7c8ebf77c4c1 #xe61c1979f7dd4eaeb9a72a2370c0e757 p
{margin: 0px;}

</style><style id="css_styles" type="text/css"><!--blockquote.cite { margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc }

blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding-top: 0px; }
a img { border: 0px; }
li[style='text-align: center;'], li[style='text-align: center; '], li[style='text-align: right;'], li[style='text-align: right; '] { list-style-position: inside;}
body { font-family: Consolas; font-size: 11pt; }
.quote { margin-left: 1em; margin-right: 1em; border-left: 5px #ebebeb solid; padding-left: 0.3em; }

</style></head>

<body><div><span>------ Original Message ------</span></div><div>
<div>From "Eddie Chapman" &lt;<a href="mailto:eddie@ehuk.net">eddie@ehuk.net</a>&gt;</div>
<div>To <a href="mailto:gentoo-dev@lists.gentoo.org">gentoo-dev@lists.gentoo.org</a></div>
<div>Date 30.03.2024 16:17:19</div>
<div>Subject Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo</div></div><div><br /></div>
<div id="x3f9c34ed207845e" class="plain"><blockquote cite="d696ac9577fae8e6e3b28aab4e3f4fe0.squirrel@ukinbox.ecrypt.net" type="cite" class="cite2">

<div class="plain_line">Michał Górny wrote:</div>
<blockquote type="cite" class="cite">
<div class="plain_line"> On Sat, 2024-03-30 at 14:57 +0000, Eddie Chapman wrote:</div>
<div class="plain_line"> </div>
<blockquote type="cite" class="cite2">
<div class="plain_line"> Note, I'm not advocating ripping xz-utils out of tree, all I'm saying</div>
<div class="plain_line"> is wouldn't it be nice if there were at least 2 alternatives to choose</div>
<div class="plain_line"> from? That doesn't have to be disruptive in any way, people who wish to</div>
<div class="plain_line"> continue using and trusting xz-utils should be able to continue to do so</div>
<div class="plain_line"> without any friction whatsoever.</div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line"> So, you're basically saying we should go out of our way, recompress all</div>
<div class="plain_line"> distfiles using two alternative compression formats, increase mirror load</div>
<div class="plain_line"> four times and add a lot of complexity to ebuilds, right?</div>
<div class="plain_line"> </div>
<div class="plain_line"> --</div>
<div class="plain_line"> Best regards,</div>
<div class="plain_line"> Michał Górny</div>
<div class="plain_line"> </div>
</blockquote>
<div class="plain_line"> </div>
<div class="plain_line">Yes that's a very good point, that was something I was wondering in</div>
<div class="plain_line">weighing up both sides, what the costs would be practically, as I don't</div>
<div class="plain_line">know the realities of running Gentoo infrastructure. And maybe the costs</div>
<div class="plain_line">is just too high of a price to pay.</div>
<div class="plain_line"> </div>
<div class="plain_line">I wonder if increased use of git repos rather than distributed tarballs</div>
<div class="plain_line">could be part of a solution to those issues, although that could put quite</div>
<div class="plain_line">a storage burden on every user. Unless they were all shallow git pulls and</div>
<div class="plain_line">the user could optionally choose to tar up the git directory after clone</div>
<div class="plain_line">with compression. But yes granted then there is even more ebuild</div>
<div class="plain_line">complexity.</div>
<div class="plain_line"> </div></blockquote><span>Huh ... I read your original message as </span></div><div id="x3f9c34ed207845e" class="plain"><span><br /></span></div><div id="x3f9c34ed207845e" class="plain"><span>"wouldn't it be nice to have at
least 2 alternative [implementations of xz-utils]</span></div><div id="x3f9c34ed207845e" class="plain"><span>to choose from"</span></div><div id="x3f9c34ed207845e" class="plain"><span><br /></span></div><div id="x3f9c34ed207845e" class="plain"><span>As
long as the file format itself is not inherently messed up, the archives</span></div><div id="x3f9c34ed207845e" class="plain"><span>could stay as .xz, only a "minimal" unxz (similar to unrar) would be required</span></div><div id="x3f9c34ed207845e" class=
"plain"><span>to access the contents.</span></div><div id="x3f9c34ed207845e" class="plain"><span><br /></span></div><div id="x3f9c34ed207845e" class="plain"><span>Regards,</span></div><div id="x3f9c34ed207845e" class="plain"><span>s.</span></div>


</body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)