Peter Humphrey posted on Thu, 20 Jun 2024 16:42:38 +0100 as excerpted:
> Hello,
>
> Is it possible to build KDE/Plasma on my Gentoo boxes, without noto
> fonts?
Short answer yes! =:^) Much (much!) longer discussion below.
> Disk space may be cheap, but still, 2100 fonts lying around do
> get in the way.
> Provided that DejaVu fonts remain available, I shall never use noto.
Gentoo: getting rid of noto fonts, while using kde/plasma which otherwise
"requires" them.
General intro: Note that this technique can be used in general, that is
for other packages too, but whether it's easily doable depends on what
sort of depend it is: RDEPENDs (runtime) in particular tend to be much
easier to fake or edit out of the build while normal DEPENDs tend to be
libraries and headers actually linked in (tho some are conditionally so --
USE-flag controlled) and thus very difficult to eliminate (unless they
/are/ USE-flag optional) -- you often have to choose between eliminating
the package that DEPENDs on them too or keeping both. See the ebuild (5)
manpage for a description of the other types of depends, with the
individual descriptions being big hints as to how easy they are to
eliminate. (In general, if it's not an RDEPEND as well, just the same as
if it's RDEPEND only, you can often remove it some way or other, almost
certainly from the run-target system, and possibly from the build system
altho that may require hacking up a substitute script or something.)
First query what depends on it. This won't tell us what type of depend it
is but it'll tell you how many packages depend on it in /some/ way:
$ equery depends noto
* These packages depend on noto:
kde-plasma/plasma-integration-9999 (media-fonts/noto)
That is what I get, just one package (good).
Now we need to see just what sort of dependency it is. Look in the ebuild
for the named package -- if you don't see it there try the eclasses
inherited by the package as they may well add the dep (you can use grep or
your fileman GUI/TUI find to see which one before opening it).
As the above suggests I'm running the live-git -9999 packages from the
gentoo/kde overlay, so that's the ebuild I'll be excerpting below. Again,
use your text-editor's string-finder to look for the string of interest,
here, noto (or /noto or with the full category too if the first result has
too much noise... not a problem in this case). Turns out there's just two
hits, and we're in luck as they're in RDEPEND only, no linking to them
(expected, it's a font!) and apparently no actual CMAKE checks for noto at
build-time either. =:^) (I have my text-editor set to show line numbers,
and it's a TUI run in konsole, mcedit FWIW, so they show up in the select/
paste and are thus prefixed below.)
68 RDEPEND="${COMMON_DEPEND}
69 media-fonts/hack
70 media-fonts/noto
71 media-fonts/noto-emoji
72 "
As an RDEPEND only they should be easy enough to either fake or edit out
of the ebuild. Note that depending on the package, this may be near
unnoticeable at runtime or may eliminate functionality you decide is
critical, but kde, at least, tends to behave reasonably sanely (continuing
gracefully without the functionality instead of just crashing, for
instance) when such deps are not there.
This is in fact how I get away with (or have gotten away with when they
were required at various times) running kde/plasma without the "required"
polkit (I don't want my GUI user changing superuser-privs-required
settings anyway), pipewire (I can do without spectacle screenshotting,
taskbar thumbnailing, and /definitely/ flatpack-portal functionality),
xdg-desktop-portal-kde (flatpack portals again), udisks (don't need the
mounting tools, etc, it enables -- at the expense of pulling in all sorts
of crap deps I don't want). If those packages aren't available it just
does without them, perhaps logging a warning or some such, and eliminates
the functionality that would be provided if they were there.
Presumably the same should happen with a missing noto, altho I actually
find it useful here, in particular because noto provides some of the
fancy-plane UTF characters often missing from most fonts, and sometimes
I /want/ some of them (tho Deja-vu provides a lot of them too), so I
haven't tried removing the noto RDEPEND this way.
OK, now you have to choose:
1) fake the dependency
2) edit it out of the ebuild
1) Ebuild editing: If as I do you have an epatch-like arrangement setup in
your update scripts that auto-applies ebuild/eclass/etc patches on update
by dropping the patch in the appropriate /etc/portage/ subdir (/etc/
portage/patches.ebuild here), just like portage automatically does for
upstream sources with patches dropped in the appropriate /etc/portage/
patches subdir, then editing the ebuild and having that carry thru to
updates isn't a /big/ thing. Otherwise, you'll be stuck manually editing
the new ebuilds on updates, which would suck, so you'll probably want to
fake the dependency and leave the ebuild alone.
2) Faking the dependency (which I normally do anyway, leaving the ebuild
patching for non-dep fixes), again, two choices:
2.1) portage-legacy package.provided
2.2) fake-package in your overlay
2.1) Use portage's legacy package.provided functionality -- I've not used
this for years so I can't guarantee it still works but the documents still
mention it, so I /think/ it does. See package.provided in the portage (5)
manpage for the details.
(Assuming it still works) This option should be the simplest in most
cases, just add a package cat/name/version line to the file in question
and call it good. But it's considered deprecated/legacy (at least by
some) because unlike option 2.2 below, it predates USE-flag dependencies
and thus while it allows you to say "I have this package installed so
don't worry about it", it does *NOT* allow you to say "I have this package
installed, with the option controlled by USE flag XXXX turned on
(alternately off), so act as if it's installed with that USE flag on
(off)."
So while simplest when it works (as it should for the simple noto RDEPENDs
above) it's sometimes /too/ simple and doesn't do what the dependency may
actually be requiring.
2.2) Create a fake/virtual package in your overlay of the appropriate
version, with IUSE lines and the like as necessary, but unlike the /real/
package, installing no actual files (part of what you're worried about
here), pulling in no sources (the real kicker with noto, given the gig-
plus size of the sources!), and having no dependencies of its own (what
I'm worried about with the udisks package, for instance).
This is what I do here, both because it /does/ give me control over fake
USE flags and anything else I might want to fake with the package (slots
are another one that can come up, see the udisks discussion below), and
because unlike package.provided, portage uses the same code-path for my
fake package as it does any other, so I don't have to worry about support
for it bitrotting or someone deciding the legacy isn't worth maintaining
any longer and removing it.
Now consider versioning. Regardless of which faking method you choose,
you still need a fake-version strategy. Here's what I use; it works for
me with overlay-fake-package versioning and should work as well for
package.provided versions too. Of course you don't have to use it, but if
it saves having to devise your own scheme, why not?
Consider that live-git packages use -9999 or a variant, say 5.x.9999 for
kde slot 5 packages. In part that's because few packages get up that high
with their version number so it's a good one to say "beyond anything else
in that slot". I thought about going one more nine and using -99999, but
decided I was lazy and the risk with a simple -999 pattern was low
/enough/, plus I could always make a one-off exception if a package
actually ever /did/ have 999 version segment (or... well, see the date-
version discussion below, since it applies to noto) that I wanted to "be
larger than" while still in the same "slot".
So my overlay has "JED/virtual"s (JED being my initials) for, for
instance:
app-arch/gzip-999
app-arch/tar-999
These are there because at least when gentoo first introduced the app-
alternative/ category variants, some packages hadn't switched to app-
alternatives for their deps yet, and I chose something other than the
originals, which I wanted to remove. Both of these are mature packages
with little change and the default slot-0, so -999 is appropriate.
sys-apps/xdg-desktop-portal-999
kde-plasma/xdg-desktop-portal-kde-9999
So kde-plasma/kwin-9999 (live-git) depends on xwayland[libei], which in
turn pulls in sys-apps/xdg-desktop-portal. I've no use for flatpack and
thus no use for the portal functionality. The generic portal is slot-0 so
I went with -999. Meanwhile kde-plasma/plasma-integration is the only
thing pulling in the portal-kde variant, luckily as a PDEPEND only
(effectively RDEPEND only for our discussion), and I'm live-git -9999 for
nearly all of kde-*, so I make the JED/virtual a -9999 to match. And
gentoo/kde packages often want same-version of stuff so matching that
-9999 prevents problems with that.
sys-fs/udisks-2.999:2
This is pulled in by kde-frameworks/solid (live-git -9999 of course) as an
RDEPEND. Note the slot-2, which is specified in solid's RDEPEND as
sys-fs/udisks:2
I'm not at all sure whether package.provided would handle a slot-specifier
properly or not -- I suspect not but as I said I've not used
package.provided in years, so maybe they updated it to do so??
Anyway, no problem with a JED/virtual; I simply specify slot=2 in the fake
package and that's that.
And the 2.999 version I chose reflects that slot. Presumably if they ever
come up with an incompatible version 3.x it'll be slotted accordingly. Of
course it's possible early 3.x testing versions might actually be
versioned 2.90+ or 2.990+ or some such, but right now the dep I'm filling
is actually a slot-dep, and I can deal with anything weird in the unlikely
event it happens some day.
As for noto... All in-tree versions are date-versioned like 20240531 or
similar, all default slot-0. I haven't had to JED/virtual a date-version
yet so it's new and I'm coming up with this on the fly, but given that
it /is/ a date-version, if I were faking it here, I'd probably choose a
version like 20991231 (still pretty clearly a date-version), or maybe
20690099 (the year still is date-versioned, the rest not; if I make it to
2069 I'll be rather lucky as I'll be 102, so either way, I don't imagine
I'd be worrying about it by then... and if by some fortune I am and they
didn't do something else like change the slot or something in the mean
time, upping it to 2099xxxx isn't /that/ hard! =:^)
I guess you can take it from there and do noto-emoji on your own...
--
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
