TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]

Jonathan Underwood jonathan.underwood at gmail.com
Sun Jul 27 13:20:11 UTC 2008


2008/7/27 Vasile Gaburici <vgaburici at gmail.com>:
> The TeXNaming draft guidelines
> [https://fedoraproject.org/wiki/PackagingDrafts/TeXNaming] seem to
> indicate that "tex" should go before the package name. E.g.
> tex-foo-fonts, and perhaps latex-foo-fonts as well. I don't know if
> ConTeXt needs any special bits for fonts, but in Fedora it gets
> packaged separately as texlive-context. The only bit that surely
> doesn't need anything special is texlive-xetex, which can use the
> system fonts.
>
> A minor issue: dvipdfm and dvipdfmx don't have a tex prefix in their
> package names, even though both put files in the system texmf tree. I
> don't know if they're usable without TeX installed, but I kinda doubt
> it...
>

Yes, that should maybe be fixed up, and one could also make the same
argument for xdvik, I suppose. The notion of prefixing with tex- was
really meant for addon class file packages for tex, rather than binary
programs. But I see your point entirely.

> There draft guidelines say that there are several ways to specify the
> "Requires:" for TeX. But on a recent review, I got this:
> ? MUST: The package must meet the Packaging Guidelines .
> The Requires for texlive-latex should be replaced with Requires: tex(latex)
>
> The sooner this gets sorted out the better...
>

Yes, it's a mess, and now it's starting to impact progress with
resolving the font issues. I had started to make some headway with
packaging guidelines a while back, and Patrice had also tackled it,
but between us we've dropped the ball.

In actual fact, the reason that I had made little headway is that when
you start to look at the problem carefully you start to realize that
it's a bit of a mistake for Fedora to be repackaging the texlive
distribution rather than packaging the individual upstream projects.
However, texlive does provide some really handy package integration
that we rely on, so we need to make use of that work. We've slowly
been making some progress splitting things out, but there's not many
packagers who seem to care much about TeX, alas.

Anyway, here's some things I see as a bit of a priority:

1) Form a TeX SIG.
2) Get some TeX packaging guidelines in place
3) Work with the fonts SIG to resolve the fonts mess.


Regarding 3, it seems to me that there's in principle nothing
technically stopping us moving in the direction that Nicholas paints
as desireable regarding proper system integration of the fonts (and
Nicholas is right to push for this). The approach I could imagine
working is roughly this:

For each font, create a standalone package which installs the font in
the system fonts directory, foo-fonts. During package building that
package would create and install the necessary symlinks and auxillary
files needed by tex (font metric files etc) and package them in a
subpackage, tex-foo-fonts (or maybe foo-fonts-tex). The
texlive-texmf-fonts package would then just require all of these
tex-foo-fonts packages. The tex-fontools will be really usefully for
taking care of this at package build time, so I am really glad that
Vasile Gaburici is moving that forward (and the lcdf-typetools
packaging). I think this is a better approach than using scriplets to
do the same thing at font install time if tex is installed.

Of course, until we actually try implementing such an approach, it'll
not become clear what the complications are. I have to admit, I'm not
massively familiar with the font packaging process in Fedora, but have
been reading through the wiki pages and looking at packages this
weekend - in fact I hadn't really wanted to raise a proposal until I
had a better and more complete understanding of the problem space, but
Nicholas' email has spurred me on a bit.

What do folks think? And I guess, more importantly, who's up for some work? :)

Jonathan.




More information about the Fedora-fonts-list mailing list