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 <ed...@ehuk.net> wrote: > Stefan Schmiedl wrote: > > ------ Original Message ------ > > > >> From "Eddie Chapman" <ed...@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. > > >
