From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-101587-garchives=archives.gentoo.org@lists.gentoo.org> 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 497EA158041 for <garchives@archives.gentoo.org>; Fri, 12 Apr 2024 07:19:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2063FE29F5; Fri, 12 Apr 2024 07:18:59 +0000 (UTC) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DA57AE29F2 for <gentoo-dev@lists.gentoo.org>; Fri, 12 Apr 2024 07:18:58 +0000 (UTC) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from <lnx-gentoo-dev@m.gmane-mx.org>) id 1rvBBY-00091x-4i for gentoo-dev@lists.gentoo.org; Fri, 12 Apr 2024 09:18:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Current unavoidable use of xz utils in Gentoo Date: Fri, 12 Apr 2024 07:18:51 -0000 (UTC) Message-ID: <pan$89782$ce3b566c$b96e5bf7$27fc2222@cox.net> References: <a2e3bb067a078bffaa860bdf5e11977d.squirrel@ukinbox.ecrypt.net> <CAFqVybq+3eME-SGHcdJ=H=5HFOvDa10z_bcQVHU_tXhnhzF88w@mail.gmail.com> <c11b452f-c6b3-4c63-b6d0-7a1402e082e1@ehuk.net> <pan$36f07$72e9414d$17cd16a3$85bffcbd@cox.net> <875xwy8wxo.fsf@gentoo.org> <c0b6cd8e0146cb7090563796805e4f12.squirrel@ukinbox.ecrypt.net> <963ef0b6-7c2a-4730-b09d-5a829c3ff4c0@gmail.com> <a6ee4efea30d0748b560cf772b659d8b.squirrel@ukinbox.ecrypt.net> <92ef54a0-7a49-49f3-b3cc-d38a2b9adebd@ehuk.net> <c5a2b579-8c3e-45c7-b859-b41a675d15d5@gentoo.org> Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> 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 User-Agent: Pan/0.155 (Kherson; 578af3b12) X-Archives-Salt: bc863dbb-7c2b-4746-8913-efcb8049f1e8 X-Archives-Hash: 45bdf184690f0bd430039ca40e126273 Joonas Niilola posted on Thu, 11 Apr 2024 08:21:39 +0300 as excerpted: > I just want to point out you > may not have to edit ebuilds at all. If xz-utils is package.provided > portage should ignore the dependency without you removing the dep from > an ebuild. package.provided: YMMV, but here rather than doing package.provided I create a "null-ebuild" for the package in my overlay. Much like virtual/* packages from which I took the idea except of course that they're named as the category/package they're replacing instead of virtual/*, null-ebuilds install no files but allow detailed control of IUSE, slot, etc, in case some of the revdeps need that. For versioning, my convention is -999 or -n.999 to imply a virtual (tho I do have a real perl bigint package v 1.999.842 installed...), much like the -9999/-n.9999 variants imply a live-package, with similar effect in terms of preferring it to any reasonable real version number as well. So for xz-utils it'd be app-arch/xz-utils-999 as it's not slotted, or app- arch/xz-utils-5.999 if it were or if something wants 5.x specifically. Or use five-nines or six-nines or ten nines... A null-pkg I actually use here? sys-fs/udisks-2.999:2 (slot 2 dep actually required by some of its rev-deps). udisks itself is a script so doesn't provide headers necessary to build other things and should be a runtime- only dep. As a script the installation itself would be too trivial to bother with, were it not for its absolutely wicked pulled-in deps for functionality I'm not going to use and don't have turned on for my kernel in any case. Luckily kde/solid/kio/etc degrade functionality gracefully if their attempted udisks calls return command-not-found, making it an ideal candidate for null-pkging. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman