[Fedora-i18n-bugs] [Bug 1806272] DejaVu has been repackaged in F32+ using new fonts packaging macros; those macros use an srpm-independent file layout and remove srpm-level sharing like the previous -common subpackage
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1806272
--- Comment #24 from Hans de Goede <hdegoede(a)redhat.com> ---
Thank you for adding the compat packages.
I must be honest though, this is not entirely what I was expecting. I was
expecting the compat symlinks to be part of the main dejavu-sans-fonts,
dejavu-serif-fonts, etc. packages. That way they will automatically just be
there, without packages depending on say dejavu-sans-fonts needing to adjust
their Requires. If someone needs to go my specfile changes to adjust the
Requires (and do a build and create an update in bodhi) they might just as well
fix the paths and be done with it.
I guess the compat packages are still useful though as a quick fix/workaround
which users can install themselves in case of pkgs where no one has gotten
around to fixing them.
Talking about fixing packages. I've spend some time thinking about how to fix
things. Most affected packages are games, typically using SDL[2]_ttf which
requires a direct file-path to a ttf file. Typically the fonts are bundled
together with other game-assets, living under /usr/share/<game-name>/font.ttf .
The Fedora pkgs replace font.ttf with a symlink, either because the font was
removed because it was non-free, or to use system-fonts instead of shipping a
private copy.
For these games my plan is to add e.g.:
BuildRequires: font(dejavusans) fontconfig
To the packages and then generate the name the symlink points to using commands
like these:
fc-match -f "%{file}" "sans"
fc-match -f "%{file}" "sans:italic"
fc-match -f "%{file}" "sans:bold"
fc-match -f "%{file}" "sans:bold:italic"
fc-match -f "%{file}" "serif"
fc-match -f "%{file}" "monospace"
The idea here is to make things more future proof, so that we can deal with any
future font-file-path changes with just a rebuild.
Before I spend a chunk of time on fixing various packages, I would appreciate
your feedback on this approach. Do you think that this is a good idea? Any
suggestions wrt the fc-match commands?
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Fedora-i18n-bugs] [Bug 1806272] DejaVu has been repackaged in F32+ using new fonts packaging macros; those macros use an srpm-independent file layout and remove srpm-level sharing like the previous -common subpackage
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1806272
--- Comment #21 from Jens Petersen <petersen(a)redhat.com> ---
(In reply to Hans de Goede from comment #17)
> 4. By far most packages which Require dejavu-*-fonts seem to Require the
> dejavu-sans-fonts package, so how about adding an /usr/share/fonts/dejavu
> symlink to /usr/share/fonts/dejavu-sans-fonts, this will fix the issues for
> apps relying on the file-path to the fonts in most cases. This reduces the
> list of apps which needs to be checked and potentially fixed because they
> rely on the serif or mono version to 24 pkgs, which is a lot better then 59.
Particularly for F32, considering how late this "Change" landed,
adding compat symlinks for dejavu at least seems a reasonable request to me.
(In reply to Nicolas Mailhot from comment #19)
> Sure, but here we have the case where <langcode> is not defined (the package
> wants some default fonts installed, it does not care which ones, as long as
> some default is installed).
> What dep should the package use in this case? I can add the generic answer
> to this question to guidelines, but I need an answer i18n, as maintainer of
> the distribution default font lists, is comfortable with
Well as of F32 'font(:lang=en)' is provided by langpacks-core-font-en, which
will pull in dejavu-sans-fonts.
I think currently that is the best option/answer (not that we want to privilege
'en' particularly...
basically for all major European languages/scripts I believe we default to
dejavu).
We can think about a better/more correct answer for F33 perhaps, but it is
tricky.
In terms of orthography English is really the lowest common denominator I
think.
Better take this to a separate discussion: feel free to open a langpacks bug to
discuss this more.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Fedora-i18n-bugs] [Bug 1806272] DejaVu has been repackaged in F32+ using new fonts packaging macros; those macros use an srpm-independent file layout and remove srpm-level sharing like the previous -common subpackage
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1806272
Nicolas Mailhot <nicolas.mailhot(a)laposte.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tagoh(a)redhat.com
--- Comment #19 from Nicolas Mailhot <nicolas.mailhot(a)laposte.net> ---
(In reply to Parag Nemade from comment #18)
> we have langpacks-core-fonts-<langcode> packages to use. They provide
> pre-defined default font for that <langcode>. If packages want to use
> particular font package they need to pull it explicitly. But if there is no
> such particular font demand then default langpacks-core-font-<langocode> can
> be used.
Sure, but here we have the case where <langcode> is not defined (the package
wants some default fonts installed, it does not care which ones, as long as
some default is installed).
What dep should the package use in this case? I can add the generic answer to
this question to guidelines, but I need an answer i18n, as maintainer of the
distribution default font lists, is comfortable with
> Yesterday I first tried to use new guidelines and
> convert some fonts packages and there I found about change in directory
> structure and fontconfig file format.
The new fontconfig format is not part of the guidelines change, you can use the
usual format, and the usual format is the one documented in guidelines and
default templates. Just set %fontconfs not %fontconfsngs.
The new format exists in my own packages as a stopgap demonstrator because
Akira wanted proof the current fontconfig format does not scale to current
needs. Also, there was no way in hell I could write and check and proof and
maintain by hand the multi-hundred/multi-thousand lines of configuration
required by some of the packaged fonts. Lastly, the current syntax does not
work at all unless you have perfect knowledge of the styles that will be
declared by your font files, so it needs brittle workarounds in %install to
generate a conf file that will only work with the exact files installed.
Simple font packages can be handled with the legacy syntax (though it is overly
verbose and painful). Complex (rich fonts) like Plex Sans, Merriweather, Droid,
Noto, etc are quite impossible to maintain without something like it.
Also, I don’t intend to maintain the new syntax generator long term. Fontconfig
syntax fixes belong in fontconfig. The generator is already way more complex
than I imagined at first, because font makers are behaving way worse than,
making current fontconfig syntax that more inadequate and harder to workaround
outside the engine itself.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Fedora-i18n-bugs] [Bug 1806272] DejaVu has been repackaged in F32+ using new fonts packaging macros; those macros use an srpm-independent file layout and remove srpm-level sharing like the previous -common subpackage
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1806272
--- Comment #18 from Parag Nemade <pnemade(a)redhat.com> ---
(In reply to Nicolas Mailhot from comment #14)
>
> > However I'm not familiar with
> > Fedora's font packaging and I'm only maintaining the weasyprint package for
> > a few months so I'd be glad to know if the current weasyprint spec file
> > needs changes. :-)
>
> The “will fail if no fonts are installed” case could not be handled
> gracefully in the past because default font groups existed solely in comps.
> Now that we have proper default metapackages I believe depending on
> 'font(:lang=en)' would work better for you in current Fedora releases.
> Though I don’t like much hardcoding a specific script.
> langpack-core-fonts-any or font(:any) would be even better if those were
> available
>
> @parag: how would i18n prefer to handle this case?
we have langpacks-core-fonts-<langcode> packages to use. They provide
pre-defined default font for that <langcode>. If packages want to use
particular font package they need to pull it explicitly. But if there is no
such particular font demand then default langpacks-core-font-<langocode> can be
used.
I am still exploring how much new guidelines are compatible with older
packaging. (I was on vacation last few days) I see fonts-rpm-macros package
already provided older macros as well so old packages can be built using new
fonts-rpm-macros package. Yesterday I first tried to use new guidelines and
convert some fonts packages and there I found about change in directory
structure and fontconfig file format. Converting existing fonts packages to new
packaging guidelines will definitely take some time due to these changes. Right
now I am trying to understand how to write fontconfig xml files for new
packaging guidelines.
If I missed to address any question here please ask again.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month
[Fedora-i18n-bugs] [Bug 1806272] DejaVu has been repackaged in F32+ using new fonts packaging macros; those macros use an srpm-independent file layout and remove srpm-level sharing like the previous -common subpackage
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1806272
--- Comment #17 from Hans de Goede <hdegoede(a)redhat.com> ---
(In reply to Nicolas Mailhot from comment #12)
> Those are just symlinks. No different from a so bump. You don’t write change
> pages for so bumps.
so-bumps are automatically picked up by dependent packages with just a rebuild,
that is not the case here. Also in case of so-bumps the person doing the
so-bump typically also does the rebuilds of dependent packages.
I seem to be spending most of my working hours lately on fixing breakage caused
by others and I'm totally fed up with having to keep fixing things which other
people broke!
My vision here is really clear: you broke it, you fix it!
I've proposed 3 different ways how *you* can fix the things which *you* broke:
1. Check which packages are affected and file bugs against them, IOW do the
minimum amount of coordination so that other people at least know that there is
breakage which needs to be fixed
2. Provide compat symlinks with the old file-paths to the files
3. Revert the part of the changes where the directory in which the font files
are stored changes. I'm fine with all the other changes, the one causing the
problem is that the directory in which the files are stored has changed.
And I'll add a 4th option:
4. By far most packages which Require dejavu-*-fonts seem to Require the
dejavu-sans-fonts package, so how about adding an /usr/share/fonts/dejavu
symlink to /usr/share/fonts/dejavu-sans-fonts, this will fix the issues for
apps relying on the file-path to the fonts in most cases. This reduces the list
of apps which needs to be checked and potentially fixed because they rely on
the serif or mono version to 24 pkgs, which is a lot better then 59.
So let me repeat myself: you broke it, you fix it, so please select one of the
options from above (I suggest combining 1 + 4) and let me know how you plan to
proceed with fixing this.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 1 month