Bug 477461 - Please convert to new font packaging guidelines
Please convert to new font packaging guidelines
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: tetex-font-cm-lgc (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Sarantis Paskalis
Fedora Extras Quality Assurance
: Reopened
Depends On: 480589
Blocks: F11-new-font-rules
  Show dependency treegraph
 
Reported: 2008-12-20 19:40 EST by Nicolas Mailhot
Modified: 2009-01-23 07:14 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-23 07:14:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2008-12-20 19:40:13 EST
This bug has been filed because we've detected your package includes one or several font files:                                                                                                                                                             repoquery -C --repoid=rawhide -f '*.ttf' -f '*.otf' -f '*.pfb' -f '*.pfa' --qf='%{SOURCERPM}\n' |sed -e 's+-[0-9.-]*\.fc[123456789]\(.*\)src.rpm++g'|sort|uniq                                                                                                                                                             Unfortunately the script does not detect symlinks to other packages, so if that's your case, you can close this bug report now.                                                                                                                                                              Otherwise, you should know that:                                                                                                                                                              - Fedora guidelines demand the packaging of fonts in a separate package or subpackage: http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages                                                                                - our font packaging guidelines recently changed, and every package that ships fonts must be adapted to the new templates available in the fontpackages-devel package. http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_(2008-11-18) http://fedoraproject.org/wiki/Fedora_fonts_policy_package http://fedoraproject.org/wiki/Simple_fonts_spec_template http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts                                                                                                                                                              Please make your package conform to the current guidelines in rawhide.                                                                                                                                                             If your package is not principaly a font package, depending on a separate font package or subpackage is the prefered solution. If your application does not use fontconfig you can always package symlinks to the files provided by the font package and installed in the correct fontconfig directories.                                                                                                                                                              It is preferred to make a font package or subpackage per font family, though it is not currently a hard guidelines requirement (it may become before Fedora 11 is released). The definition of a font family is given on http://fedoraproject.org/wiki/Fonts_spec_template_notes/font-family                                                                                                                                                              The new templates should make the creation of font subpackages easy and safe.                                                                                                                                                              The following packages have already been converted and can serve as examples: - andika-fonts - apanov-heuristica-fonts - bitstream-vera-fonts - charis-fonts - dejavu-fonts - ecolier-court-fonts - edrip-fonts - gfs-ambrosia-fonts - gfs-artemisia-fonts - gfs-baskerville-fonts - gfs-bodoni-classic-fonts - gfs-bodoni-fonts - gfs-complutum-fonts - gfs-didot-classic-fonts - gfs-didot-fonts - gfs-eustace-fonts - gfs-fleischman-fonts - gfs-garaldus-fonts - gfs-gazis-fonts - gfs-jackson-fonts - gfs-neohellenic-fonts - gfs-nicefore-fonts - gfs-olga-fonts - gfs-porson-fonts - gfs-solomos-fonts - gfs-theokritos-fonts - stix-fonts - yanone-kaffeesatz-fonts                                                                                                                                                           If you have any remaining questions about the new guidelines please ask them on fedora-fonts-list at redhat.com
Comment 1 Nicolas Mailhot 2008-12-20 19:57:15 EST
[Since the bot made a mess of the text here it is again in properly indented form.]

This bug has been filed because we've detected your package includes one or several font files:

repoquery -C --repoid=rawhide -f '*.ttf' -f '*.otf' -f '*.pfb' -f '*.pfa' --qf='%{SOURCERPM}\n' |sed -e 's+-[0-9.-]*\.fc[123456789]\(.*\)src.rpm++g'|sort|uniq

Unfortunately this script does not detect symlinks to other packages, so if that's your case, you can close this bug report now.

Otherwise, you should know that:

— Fedora guidelines demand the packaging of fonts in a separate package (or subpackage):
http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages

— our font packaging guidelines recently changed, and every package that ships fonts must be adapted to the new templates available in the fontpackages-devel package:
  – http://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation_(2008-11-18)
  – http://fedoraproject.org/wiki/Fedora_fonts_policy_packagehttp://fedoraproject.org/wiki/Simple_fonts_spec_templatehttp://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts

Please make your package conform to the current guidelines in rawhide (you can use the fontpackages package in F9 or F10 to test, but only submit changes to rawhide please).

If your package is not principaly a font package, depending on a separate font package or subpackage is the prefered solution. If your application does not use fontconfig you can always package symlinks to the files provided by the font package and installed in the correct fontconfig directories.

It is preferred to create a font package or subpackage per font family, though it is not currently a hard guidelines requirement (it may become before Fedora 11 is released). The definition of a font family is given on:
http://fedoraproject.org/wiki/Fonts_spec_template_notes/font-family

The new templates should make the creation of font subpackages easy and safe.

The following packages have already been converted by their packager and can serve as examples:
❄ andika-fonts
❄ apanov-heuristica-fonts
❄ bitstream-vera-fonts
❄ charis-fonts
❄ dejavu-fonts
❄ ecolier-court-fonts
❄ edrip-fonts
❄ gfs-ambrosia-fonts
❄ gfs-artemisia-fonts
❄ gfs-baskerville-fonts
❄ gfs-bodoni-classic-fonts
❄ gfs-bodoni-fonts
❄ gfs-complutum-fonts
❄ gfs-didot-classic-fonts
❄ gfs-didot-fonts
❄ gfs-eustace-fonts
❄ gfs-fleischman-fonts
❄ gfs-garaldus-fonts
❄ gfs-gazis-fonts
❄ gfs-jackson-fonts
❄ gfs-neohellenic-fonts
❄ gfs-nicefore-fonts
❄ gfs-olga-fonts
❄ gfs-porson-fonts
❄ gfs-solomos-fonts
❄ gfs-theokritos-fonts
❄ stix-fonts
❄ yanone-kaffeesatz-fonts

If you have any remaining questions about the new guidelines please ask them on:
fedora-fonts-list at redhat.com
Comment 2 Nicolas Mailhot 2009-01-11 10:20:22 EST
To help packagers manage the transition to the new guidelines, we've published the following FAQ

http://fedoraproject.org/wiki/Shipping_fonts_in_other_packages_(FAQ)
Comment 3 Sarantis Paskalis 2009-01-12 05:48:07 EST
Fixed in 0.5-11 (rawhide)
Comment 4 Nicolas Mailhot 2009-01-12 18:24:38 EST
Thank you for working on this I realise it's not easy to be the first TEX packager to adapt your packages. Anyway, some QA feedback:

1. you need to add the template (build)requires on fontpackages* for build mock/koji to work

2. you have several different font families in this package.

http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#What_is_this_font_family_thing.3F

Each one needs a separate font subpackage
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#How_many_font_files_can_I_put_in_a_font_.28sub.29package.3F

3. since you'll have multiple font subpackages, you need to create a common subpackage they depend on that will own the font package directory and the fonts COPYING

4. I'm not sure your (duplicated) %define fontpkg \-n\ cm-lgc-fonts is a good idea then.

5. are you sure you can not use a subpackages named srpmname-foo? Removing the srpmname prefix will confuse users.

6. some fontconfig files would be nice, there are good templates in fontpackages-devel
Comment 5 Sarantis Paskalis 2009-01-13 04:41:59 EST
Thanks for the feedback.

(In reply to comment #4)
> Thank you for working on this I realise it's not easy to be the first TEX
> packager to adapt your packages. Anyway, some QA feedback:
> 
> 1. you need to add the template (build)requires on fontpackages* for build
> mock/koji to work

Bah, I would swear I had them in earlier versions.  Will fix.

> 2. you have several different font families in this package.
> 
> http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#What_is_this_font_family_thing.3F
> 
> Each one needs a separate font subpackage
> http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#How_many_font_files_can_I_put_in_a_font_.28sub.29package.3F

I am aware of that.  However, the separation of the font families is a somewhat more difficult problem (the filenames are not so intuitive), so I left them to a later point in time.   Well, ok I will give it a shot, since I already did it to mgopen-fonts.

> 3. since you'll have multiple font subpackages, you need to create a common
> subpackage they depend on that will own the font package directory and the
> fonts COPYING

OK.

> 4. I'm not sure your (duplicated) %define fontpkg \-n\ cm-lgc-fonts is a good
> idea then.

Thanks for pointing to the duplication.  

What I was trying to do is having a subpackage name in line with other font packages (such as mgopen-fonts) instead of (te)tex-font-cm-lgc).  Since a rename of the package is in order, and the font packages already carry the %{fontname}-fonts name, cm-lgc-fonts fits for the srpm name, cm-lgc-fonts-common, cm-lgc-fonts-roman, etc for the different families, and tex-fonts-cm-lgc for the TeX specific stuff.

I think that would be the straightforward way of dealing with the mess

The alternative would be to call the srpm tex-fonts-cm-lgc and suffix it with -common, -roman, -sans, etc.  This, however, leads to names such as tex-font-cm-lgc-roman, which is not compatible with the rest of the fedora font packages.

> 5. are you sure you can not use a subpackages named srpmname-foo? Removing the
> srpmname prefix will confuse users.

See above.

> 6. some fontconfig files would be nice, there are good templates in
> fontpackages-devel

OK, I will come up with some fontconfig stuff for the families only (the encodings are a really dark area).
Comment 6 Nicolas Mailhot 2009-01-13 05:36:56 EST
(In reply to comment #5)
>  Since a
> rename of the package is in order

Since IIRC the TEX packagers are preparing a mass rename TEX-side, and FPC is discussing changing the font package naming conventions to make them more "consistent", it's probably a good idea to discuss all this with spot so all the conflicting requirements may be made to fit somehow

Or you'll need another rename run later.
Comment 7 Sarantis Paskalis 2009-01-13 06:13:01 EST
I see.

The current package is named tetex-font-cm-lgc.
My proposal is to name the base package cm-lgc-fonts, split into subpackages cm-lgc-fonts-roman, cm-lgc-fonts-sans, cm-lgc-fonts-typewriter and cm-lgc-fonts-common.  The TeX specific stuff is put in a subpackage name tex-fonts-cm-lgc (note that it is not a suffix of the main package, but I think the main focus of this package is the font itself rather than the enhancement of TeX).

I am open to suggestions.

Anyway, my altered specfile (and srpm) is currenly at 
http://gallagher.di.uoa.gr/any/rpms/cm-lgc-fonts/
Comment 8 Nicolas Mailhot 2009-01-13 06:56:25 EST
(In reply to comment #7)
> I see.
> 
> The current package is named tetex-font-cm-lgc.
> My proposal is to name the base package cm-lgc-fonts, split into subpackages
> cm-lgc-fonts-roman, cm-lgc-fonts-sans, cm-lgc-fonts-typewriter and
> cm-lgc-fonts-common.  The TeX specific stuff is put in a subpackage name
> tex-fonts-cm-lgc (note that it is not a suffix of the main package, but I think
> the main focus of this package is the font itself rather than the enhancement
> of TeX).

I'd rather avoid putting the affix used to identify pure font packages in a pure TEX package, but I guess it's ok here.

@spot:
Another solution would be to make have all binary font (sub)packages named srpmname-fontname-font so we could have

srpm
cm-lgc-fonts

rpm
cm-lgc-fonts-common (directory ownership, licensing files and other doc)
cm-lgc-fonts-fontname1-font
cm-lgc-fonts-fontname2-font
...
cm-lgc-fonts-fontnameX-font
cm-lgc-fonts-tex (TEX parts)

this way every pure font package could end in -font, and every pure tex package in -tex

The only drawback is that for font packages that contain a single font family you'll have to force subpackaging and accept redundant naming like

srpm
gfs-olga-fonts

rpm
gfs-olga-fonts-olga-font

But it should work in all cases and produce consistent names. Including in non-font srpms

srpm
openoffice.org

rpm
openoffice.org-opensymbol-font

(Another variant for single-font packages would be to use

srpm
gfs-olga-fonts

rpm
gfs-olga-font

forcing a renaming but probably not too confusing to users)

There are many possible choices, and they all fail if not applied consistently, so I hope FPC settles on one before each packager chooses a different option.
Comment 9 Sarantis Paskalis 2009-01-13 07:35:39 EST
(In reply to comment #8)

> rpm
> cm-lgc-fonts-common (directory ownership, licensing files and other doc)
> cm-lgc-fonts-fontname1-font
> cm-lgc-fonts-fontname2-font
> ...
> cm-lgc-fonts-fontnameX-font
> cm-lgc-fonts-tex (TEX parts)

(I am not sure this discussion belongs here, but this is the only proposal I am not really confortable with).  I don't like the repetition of the f*  word (font), so I would prefer it appears only once (I don't mind where).
Comment 10 Nicolas Mailhot 2009-01-13 08:04:56 EST
(In reply to comment #9)
> (In reply to comment #8)
> 
> > rpm
> > cm-lgc-fonts-common (directory ownership, licensing files and other doc)
> > cm-lgc-fonts-fontname1-font
> > cm-lgc-fonts-fontname2-font
> > ...
> > cm-lgc-fonts-fontnameX-font
> > cm-lgc-fonts-tex (TEX parts)
> 
> (I am not sure this discussion belongs here,

@spot:
I don't really know where the discussion is now that FPC has started working on it either :( I hope spot does something with all the info I CC him)

> but this is the only proposal I am
> not really comfortable with).  I don't like the repetition of the f*  word
> (font), so I would prefer it appears only once (I don't mind where).

I guess we could do something like

srpm
cm-lgc-fonts

rpm
cm-lgc-fonts-common (directory ownership, licensing files and other doc)
cm-lgc-fontname1-font
cm-lgc-fontname2-font
...
cm-lgc-fontnameX-font
cm-lgc-tex (TEX parts)

srpm
gfs-olga-fonts

rpm
gfs-olga-font

srpm
dejavu-fonts

rpm
dejavu-fonts-common
dejavu-sans-font
dejavu-serif-font
dejavu-sans-mono-font

srpm
openoffice.org

rpm
openoffice.org-opensymbol-font
(and openoffice.org-name2-font + openoffice.org-fonts common if it ever grows another font)

It is more æsthetically pleasing, but implies many packages where rpmname != srpm-name-foo. Though the variation is small enough that users could probably not notice. However that may make it a bit harder to document in guidelines

Also that sort of breaks if you have a srpm named foo-fonts and a srpm named foo in the repo (don't think that's the case right now, may happen)
Comment 11 Nicolas Mailhot 2009-01-13 18:27:25 EST
After a mail exchange with Tom the new naming rules will probably look like that
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_(2009-01-13)

As your package is one of the most complex naming-wise please check you're ok with the proposal (or suggest amendments)

As for the split in subpackages, please note that
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_%282008-12-21%29

explicitelly authorises grouping of "font families which are designed to extend other font families with larger Unicode coverage", so you don't need to create a different subpackage for all the regional parts of CM roman, for example

(though the fontconfig part will probably need some work with behdad)
Comment 12 Sarantis Paskalis 2009-01-14 04:14:14 EST
(In reply to comment #11)
> After a mail exchange with Tom the new naming rules will probably look like
> that
> http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_(2009-01-13)
> 
> As your package is one of the most complex naming-wise please check you're ok
> with the proposal (or suggest amendments)

I am ok with most of the proposal.  I have some doubts about the TeX-related subpackage.

One is whether tex should be a prefix or a suffix.

The other is whether the foundry name (ctan) should be in the package name.  After all, we do not name all the perl modules perl-cpan-perlmodule.

But I guess this is not so critical, can be left unspecified (it is after all a TeX related subpackage) and wait for some input from the TeX guys.  

(My preference would be that tex should be a prefix and the ctan deleted as in tex-cm-lgc).
Comment 13 Nicolas Mailhot 2009-01-14 04:30:58 EST
The "ctan" bit is to be consistent with the other "foundry" prefixes.

For the TEX part, since it's unlikely to be the only tex subpackage a suffix will be a lot easier to manage for you I think. But anyway please agree with other TEX guys on a naming convention there. Once the fonts naming proposal is officialized this naming example will be part of guidelines and much harder to change.
Comment 14 Nicolas Mailhot 2009-01-14 13:38:01 EST
FPC approved those two additional guidelines recently, please take them into account if you need to create or update a fonts package or subpackage:

– 2009-01-14: naming
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_%282009-01-13%29

— 2009-01-06: exact splitting rules
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_%282008-12-21%29

(packagers that can drop font files and just depend on an existing font package are not impacted)
Comment 15 Nicolas Mailhot 2009-01-15 03:31:06 EST
The "fontpackages-*-1.14" packages from rawhide (templates and macros) should enable you to respect the new naming easily (feel free to name the tex subpackage as you want)
Comment 16 Nicolas Mailhot 2009-01-18 16:41:53 EST
And FESCO approved the FPC naming changes so there's no longer any reason to wait
Comment 17 Sarantis Paskalis 2009-01-19 06:23:07 EST
Opened up a review request for the renaming of the package.  As discussed in fedora-devel [1], renaming needs a re-review.

http://article.gmane.org/gmane.linux.redhat.fedora.devel/93869
Comment 18 Sarantis Paskalis 2009-01-21 09:17:48 EST
ctan-cm-lgc-fonts built in rawhide.  Closing.
Comment 19 Alex Lancaster 2009-01-22 04:11:15 EST
Still some problems, tetex-fong-cm-lgc is still in the rawhide report as of:

http://koji.fedoraproject.org/mash/rawhide-20090122/logs/depcheck

Broken deps for i386
----------------------------------------------------------
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts

I suspect you need to follow the EOL procedure:

http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife

and request rel-eng to block the old name.  Re-opening in the meantime.
Comment 20 Sarantis Paskalis 2009-01-23 07:14:16 EST
Ah, sorry forgot that one from the EOL procedure.

Blocked from dist-f11 in koji (https://fedorahosted.org/rel-eng/ticket/1243).

Thanks

Note You need to log in before you can comment on or make changes to this bug.