From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7B9B3158041 for ; Thu, 4 Apr 2024 14:25:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B74FB2BC015; Thu, 4 Apr 2024 14:24:57 +0000 (UTC) Received: from james.steelbluetech.co.uk (james.steelbluetech.co.uk [78.40.151.100]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4D5ACE2A3B for ; Thu, 4 Apr 2024 14:24:56 +0000 (UTC) Received: from ukinbox.ecrypt.net (hq2.ehuk.net [10.0.10.2]) by james.steelbluetech.co.uk (Postfix) with ESMTP id DED77BFC18 for ; Thu, 4 Apr 2024 15:24:54 +0100 (BST) DKIM-Filter: OpenDKIM Filter v2.10.3 james.steelbluetech.co.uk DED77BFC18 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ehuk.net; s=default; t=1712240694; bh=7K2XwbiLBs+IHCXloHr4puCRnuBvDkALnWppcO0N9xg=; h=In-Reply-To:References:Date:Subject:From:To:Reply-To:From; b=Ov7TRE6G7oIm9lwK1K3GIiZSI8xp5Nk5v+BaPDw/N9FFUOCDtzahCIPU1Mm8LeT9+ yQIQTG4uscornLLwnaJmoHFLwsESzUtyr+mt2cNsY9AbVnUO2lTvj80hJgsUYHc2/T 4LAVkpnxmITnYdmeWFVr8YZsj7f5eaDSLW1df0JhNw2I5yrHK5CktK48DGBzQrZ6It h65avBYCwDzAmkNEdDeToBPWUV7V1C261OfR0tvpJUxkH/SufgVaQYPTat8f52OaQY 0i2tDVLUUUICtrBouJqqCDEd5yhJDXwUu/eJ/e3/ErhL3kZwPM+L8Q4F2leDzPEssM VAHSTO1qaWONw== Message-ID: In-Reply-To: <963ef0b6-7c2a-4730-b09d-5a829c3ff4c0@gmail.com> References: <875xwy8wxo.fsf@gentoo.org> <963ef0b6-7c2a-4730-b09d-5a829c3ff4c0@gmail.com> Date: Thu, 4 Apr 2024 15:24:54 +0100 Subject: Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo From: "Eddie Chapman" To: gentoo-dev@lists.gentoo.org User-Agent: SquirrelMail/1.5.2 [SVN] Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang X-Archives-Salt: cf449547-b9db-498c-b5a6-31dfe80b0fff X-Archives-Hash: 09a94f7fc92daa3ca799079229fd2c2c 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.