[Bug 1805779] Review Request: pt-sans-fonts - A grotesque
pan-Cyrillic font family
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1805779
--- Comment #16 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
That’s i18n land, so not my stuff to complain about, but most of the comps
fonts stuff is obsolete unmaintained junk.
1) "authoring-and-publishing" group pulls "tex-fonts-hebrew" → completely
useless, we’ve have had Hebrew support in the default system font for 13 years
now
2) "design-suite" group needs many fonts packages → is anyone maintaining
those? I haven’t seen anyone design-side bothering about fonts for 5/7 years at
least
3) "electronic-lab" group installs "xorg-x11-fonts-*" → that is obsolete now
that wayland is here and legacy font format support is gone from harfbuzz-ng
4) "engineering-and-scientific" group installs "stix-math-fonts" → this has
been gone upstream for years and it is gone in F33 too now
5) "fonts" group itself → replace it will langpacks
6) "gnome-desktop" comps group installs → don’t get me started on how GNOME is
unable to work with the rest of the distribution
7) Then we still have "legacy-fonts" → death row corner from ~13 years ago.
Just let them go
So, not impressed at all with this list. Just remove the damn groups (or fill
them with langpacks). Two competing systems won’t make one working system. Two
competing systems mean two broken systems. No one will maintain two lists of
fonts (tedious and pretty useless work). Please don’t stop in the middle of the
river, finish the transition.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Bug 1805779] Review Request: pt-sans-fonts - A grotesque
pan-Cyrillic font family
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1805779
--- Comment #15 from Parag AN(पराग) <panemade(a)gmail.com> ---
Let me explain langpacks history.
Previously when Workstation was producing DVD iso, anaconda team helped to hook
the code to also install required langpacks based on selected language
supports. E.g. if you install Fedora in Japanese language and also enabled
French then you was getting both language support installed on your system.
Also, DVD iso contained all required packages already.
Then the decision comes to drop DVD iso for Workstation and only Live iso, this
created challenge to have langpacks installed automatically when you installed
Live iso on your harddisk. We then dropped dnf-langpacks package and moved to
langpacks metapackage concept in Fedora 24. Then I tried to keep maintaining
system-config-language tool that some users demanded to install langpacks. Then
we again went into discussion to find some solution to have langpacks
auto-installed. I developed some tool "langpacks-install" but again it was not
complete solution.
We also keep working on enhancing langpacks usage by end users and also in
containers.
In Fedora 30, we implemented
https://fedoraproject.org/wiki/Changes/Replace_Comps_Language_Group_With_...
, so comps language support groups (e.g. japanese-support or hindi-support) was
gone.
In Fedora 31, we implemented
https://fedoraproject.org/wiki/Changes/Langpacks-core , packages like
langpacks-ja need to be split to langpacks-core-ja to provide minimal i18n
support (i.e. locale, default font and any input method).
With this we kept exploring options to have langpacks-<LANGCODE> package
auto-installed on the Fedora system. We tried gnome-initial-setup but again it
was not good solution. Now, work has been done by Sundeep in gnome-software to
detect the current language of your system in Gnome and if its corresponding
langpacks metapackage is not installed then gnome-software plugin will install
it. Now, he is working on same to be working in Fedora Silverblue system.
Once we will see this auto-installation of langpacks working fine, we can think
about "fonts" comps group existence.
If it was easy way to install langpacks on Fedora system during first set of
packages installation only then we could have able to remove "fonts" comps
group.
But is listing font packages in Comps file is only related to
langpacks/language support? No, just grep "fonts" in comps-f33.xml.in file and
you will find 752 occurrence of "fonts" string in that file.
1) "authoring-and-publishing" group pulls "tex-fonts-hebrew" which installs
almost all culmus*fonts packages.
2) "design-suite" group needs many fonts packages default installed on the
system.
3) "electronic-lab" group installs "xorg-x11-fonts-*" packages default
installed on the system.
4) "engineering-and-scientific" group installs "stix-math-fonts"
5) "fonts" group itself installs 32 default fonts packages and have 595 fonts
packages marked as optional.
6) "gnome-desktop" comps group installs "adobe-source-code-pro-fonts" package
by default.
7) Then we still have "legacy-fonts" packages group which install 4 default
fonts and have 77 optional fonts packages. These are the fonts which should get
removed or converted to ttf/otf in Fedora.
Now, if we want to remove "fonts" comps group then I am not sure how these
different Desktop environments will work. E.g. kde-desktop-environment,
xfce-desktop-environment, workstation-product-environment,
lxde-desktop-environment, lxqt-desktop-environment,
cinnamon-desktop-environment, mate-desktop-environment,
sugar-desktop-environment, deepin-desktop-environment and then these other
groups developer-workstation-environment, basic-desktop-environment,
base-system will work.
I still don't see its an easy way to remove fonts group from comps file. So,
any changes to fonts name should be changed in comps file as well.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Bug 1805779] Review Request: pt-sans-fonts - A grotesque
pan-Cyrillic font family
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1805779
--- Comment #12 from Adam Williamson <awilliam(a)redhat.com> ---
Hadn't noticed that bug, that is annoying. IIRC, though, it always used to work
that way, and querying by provides as well as literal name is a fairly recent
feature, so I always used to hack up a little bash something like this:
for i in `dnf repoquery --provides foo`; do echo "PROVIDES $i"; dnf repoquery
--whatrequires "$i"; done
untested and it probably has a mistake in it somewhere, but you get the idea
anyway :)
BTW, there's I think one more reason to have the Provides: to ensure the
package actually gets installed on upgrade. I haven't checked to be sure, but
IIRC if 'new-foo' only Obsoletes 'old-foo' but doesn't Provides it, when you do
an upgrade, it's not actually guaranteed that 'new-foo' will be installed to
replace 'old-foo', it'll only happen if 'new-foo' is pulled into the
transaction for some other reason.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month