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
