Noto fonts

[Duncan]

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