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.
