[gentoo-dev] Re: Current unavoidable use of xz utils in Gentoo

[Duncan <1i5t5.duncan@cox.net>]

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