Re: Re[2]: [gentoo-dev] Current unavoidable use of xz utils in Gentoo

["Eddie Chapman" <eddie@ehuk.net>]

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.