Eli Schwartz wrote: > On 4/3/24 11:30 AM, Eddie Chapman wrote: > >> Just to report I've been able to remove app-arch/xz-utils from my own >> workstation, with 2412 packages installed and running kde. I'm going to >> roll it out to my other gentoo systems which have a lot less stuff on >> them so am confident will be fine. It's not completely trivial but not >> as difficult as I imagined it to be, certainly something an advance >> Gentoo >> user could do if they wanted, with instructions. It does involve a >> relatively small hack and functionality previously provided by xz-utils >> is replaced by app-arch/p7zip. > > > I'd just like to clarify my previous posts: what you're describing here > is neat and productive and valid to my eyes. Actually, I wish this had been > the topic of the *first* post in this thread. :) > > Replacing implementations has several great uses. There's some prior art > in make.conf, but it doesn't go far enough: > > PORTAGE_BZIP2_COMMAND > BINPKG_COMPRESS > BINPKG_COMPRESS_FLAGS > > > Disregarding the security component entirely, one might wish to use pixz > or pigz instead of the default programs. Why not 7zip as well?
One of my emails elsewhere in this thread (easy to miss in a long thread, I know) I discussed pixz, pigz and 7zip. The former two were not suitable for me as both rely on xz utils. However I will probably switch from p7zip to the latest upstream 7zip in the near future, for reasons discussed in that email. > In terms of security, this suggests an easy and simple way both to allow > users to depclean xz-utils without sacrificing the ability to install > packages using *.tar.xz sources, and for Gentoo to roll out an update that > would do this distribution-wide if necessary via a trivial configuration > change. > > https://dev.gentoo.org/~ulm/pms/head/pms.html#section-12.3.15 may need > updating to allow this. But it seems very valid to propose doing exactly > that. I am not sure why it specifies e.g. "must ensure that GNU gzip" with > heavy ties to implementations, when it doesn't specify such for > compression. That would certainly be a nice improvement for all users if it were ever to come to pass. > I'm guessing what you did was override/hook the unpack phase helper > function and divert it to 7zip instead. ;) It would be interesting to have > actual hooks for that instead. Yes it is in the unpack phase where emerge calls /usr/bin/xz mostly. In fact I didn't have to touch emerge/portage, it was more crude, I uninstalled app-arch/xz-utils (and put it in /etc/portage/profile/package.provided) and replaced /usr/bin/xz with a bash script to behave like what the unpack phase was expecting, but using /usr/lib64/p7zip/7za to do the decompression. However, I need to do some more work on this "wrapper" (though it's more than a wrapper) as I found one package where xz is called from the install phase and my script doesn't handle that yet it just throws an error for anything other than the unpack phase case (which is 99.9 percent of packages). But ultimately doing something along the lines of what you suggest instead would of course be much better than this dirty hack (though it works just fine for me for now). Since there appears to be some interest I'll put together a single email to the list later today detailing everything, as I needed to do more things overall in addition to replacing /usr/bin/xz.
