A decompression implementation all in rust it would seem.

https://github.com/gendx/lzma-rs



On Sat, Mar 30, 2024 at 12:36 PM Eddie Chapman <eddie@ehuk.net> wrote:

> 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.
>
>
>