Removing garbage fonts but keeping virtual package consistency?

gcb · 2023-09-27 17:27:03

Using KDE i get forced to use google overkill font package. kde-desktop requires plasma-workspace which requires plasma-integration[1] which requires noto-fonts which includes 627 fonts

noto-fonts includes everything under the sun. While i welcome the internationalization, there are things there that are clearly garbage. Like old scripts that nobody uses. And ironically, the only international glyphs i need is in another package, noto-fonts-cjk. while the noto-fonts gives me pearls such as Vithkuqi... which is a toy glyph set invented by a german for the armenian alphabet in 1820 that someone found in an old library with the last mention of it by name (not even by usage) made in 1844! And someone at google decided to include it in the main noto package. great.

I have a background in linguistics and font design, and even I consider 40% of what is included in noto-fonts pure useless garbage.

But disk space is small... well, I thought so for years and ignored that, but now we have graphical designers to support in the team. And we normalized one laptop model with arch kde for everyone. The first second of graphical design is pure pain because they have to scroll 120932498570189234 noto fonts to select fonts for each element. Of course they found reddit posts full of people asking about this annoyance, and the solution is always "uninstall noto-fonts"... but if i do that now i have a "broken" virtual package for kde-desktop. sigh. if it was one machine it would be done already.

thanks for reading my blog post. any solution to this annoyance? This makes kde/plasma looks really bad for any graphical designer that ever tries it.

[1] plasma-integration: which smells like garbage on it's own self and would be nice to get rid of, if it is easier than the fonts... i don't have many qt-but-not-kde applications anyway, which is what this package aludes to improve but even the source's readme fails to say anything concrete. i don't think anybody have many qt apps. and even if we had they would not be using the interfaces this code overrides. seems like very nitty-picky for very specific edge cases the kde devs happens to care about. little hacks like optimizing global menu button prefence and such (not even fixing or changing anything, just adding a global var check optimization before the regular code)... anyway, in the end, that package just requires two fonts, perl and have a bunch of hacky scripts replacing "Oxygen-sans" with "noto-sans" all over the place. lol

gcb · 2023-09-27 17:36:14

found this convoluted workaround https://bbs.archlinux.org/viewtopic.php?id=230195 for now but still unsure if `pacman -Rdd` will screw things over next update. either by preventing update of the hacky plasma-integration package or reinstalling the fonts later on...

Awebb · 2023-09-27 17:38:49

Build your own noto-fonts, the PKGBUILD is available. There are also a bunch of noto-fonts packages in the AUR. Then there is teh NoExtract directive for pacman.conf.

EDIT: A more permanent solution would be to ask the maintainer of the noto-fonts package to split it. A lack of granularity in KDE has lead to the foundation of a KDE-mod repository and even a whole distro in the past.

Last edited by Awebb (2023-09-27 17:42:08)

gcb · 2023-09-27 18:50:41

> lack of granularity in KDE has lead to the foundation of a KDE-mod repository and even a whole distro in the past.

oh! that's not reassuring.

on arch side, a fix is apparently not welcome (though the reporters didn't attempt to formulate an argument or provide patches)
https://bugs.archlinux.org/task/68650
https://bugs.archlinux.org/task/69522
... i will try to talk with the fonts maintainer, if not the same person.

The NoExtract hack is not very good. it is *global*, not limited to a single package. it is sure to bite me later on when i least expect and will be a pain to find out the reason. ...i tried it a while ago and when built an new image to test already had one font i care about missing (from a different package heh, extra/noto-fonts-emoji) /usr/share/fonts/noto/NotoColorEmoji.ttf

If i had added that package to our systems next year, i would never recall i had that noExtract there and would waste a lot of time trying to figure out why i'm not seeing the emojis.

seth · 2023-09-27 19:44:45

It's a font
Any hard dependency on a specific font is technical nonsense, it's a dependecy so you can have the plasma-experience or whatever.

You can drop the package and put it onto the ignore list or install a dummy package that provides "noto-fonts" and does nothing else. You need *some* font, not a specific one.

If you wanna be extra careful and adhere to the reasoning in https://bugs.archlinux.org/task/68650 you could depend the dummy on your preferred font package and add a fontconfig that aliases noto to that font.
But that reason isn't entirely technical either, I doubt (hope) that anything KDE crashes if you cannot resolve Noto (because fontconfig will resolve anything that's not there to the local default, typically DejaVu but really anything that's available)

Awebb · 2023-09-27 19:46:20

Then delete them with a pacman hook. Don't go overboard with globbing and generate a file list.

gcb · 2023-09-28 13:26:19

agree with both of you. what i'm doing for now, since this is voluntary work for a non-profit and we have tons of machines, is to just ship a `-Rdd` update to everyone and deal with whatever when it happens

i asked around and absolutely no one cares for the noto fonts :shrug

Trilby · 2023-09-28 13:44:55

gcb wrote:

The NoExtract hack is not very good. it is *global*, not limited to a single package.

What does this mean? You specify files to not extract. Any given file is generally owned by a single package.

seth · 2023-09-28 13:58:58

Given the noto-emoji reference OP probably got self-owned by globbing

@gcb

# Maintainer: Me <me at here>

pkgname=noto-dummy
pkgver=1
pkgrel=1
pkgdesc="nono noto font"
arch=('any')
license=('GPL')
depends=('ttf-font')
provides=(noto-fonts)

The dummy will fulfill the requirement and ensure that some font is installed.

Awebb · 2023-09-28 14:02:28

Trilby wrote:

gcb wrote:
The NoExtract hack is not very good. it is *global*, not limited to a single package.
What does this mean? You specify files to not extract. Any given file is generally owned by a single package.

OP found some patterns for NoExtract behind the provided link that'll hit other not so unwanted noto packages as well and does not seem to be very confident about modifying those patterns. That's why I suggested writing a hook that'll delete an explicit list of unwanted files on updates of that package.

Trilby · 2023-09-28 15:20:56

Awebb wrote:

That's why I suggested writing a hook that'll delete an explicit list of unwanted files on updates of that package.

Whether it's a NoExtract or a hook is orthogonal to this problem. If there is an explicit list, NoExtract would work fine. If there is a faulty glob, it'd be just as problematic in a hook or NoExtract.

Awebb · 2023-09-28 16:09:27

That is correct. I recommended a hook with an explicit file list, because it's easy to drop a single file even under "the user has to do it" circumstances than editing an unknown number of pacman.confs in a seemingly uncontrolled environment. I'd also not want to contaminate my pacman.conf with 300-600 entries for NoExtract.

Last edited by Awebb (2023-09-28 16:09:40)

Arch Linux

#1 2023-09-27 17:27:03

Removing garbage fonts but keeping virtual package consistency?

#2 2023-09-27 17:36:14

Re: Removing garbage fonts but keeping virtual package consistency?

#3 2023-09-27 17:38:49

Re: Removing garbage fonts but keeping virtual package consistency?

#4 2023-09-27 18:50:41

Re: Removing garbage fonts but keeping virtual package consistency?

#5 2023-09-27 19:44:45

Re: Removing garbage fonts but keeping virtual package consistency?

#6 2023-09-27 19:46:20

Re: Removing garbage fonts but keeping virtual package consistency?

#7 2023-09-28 13:26:19

Re: Removing garbage fonts but keeping virtual package consistency?

#8 2023-09-28 13:44:55

Re: Removing garbage fonts but keeping virtual package consistency?

#9 2023-09-28 13:58:58

Re: Removing garbage fonts but keeping virtual package consistency?

#10 2023-09-28 14:02:28

Re: Removing garbage fonts but keeping virtual package consistency?

#11 2023-09-28 15:20:56

Re: Removing garbage fonts but keeping virtual package consistency?

#12 2023-09-28 16:09:27

Re: Removing garbage fonts but keeping virtual package consistency?

Board footer