This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 477606 - RFE: warn on fonts installed outside %_fontbasedir
RFE: warn on fonts installed outside %_fontbasedir
Status: NEW
Product: Fedora
Classification: Fedora
Component: rpmlint (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-22 06:51 EST by Nicolas Mailhot
Modified: 2010-12-07 16:18 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
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-22 06:51:16 EST
Our current font packaging policy requires the installation of TTF/OTF/PFA/PFB fonts in a subdirectory of %_fontbasedir
http://fedoraproject.org/wiki/fontpackages

Our general packaging policy demands of packagers to create proper font packages when their app bundles them
http://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages

If an app or bit of code is not fontconfig-aware, it can always package symlinks pointing to fonts packaged according to our guidelines in %_fontbasedir space, and depend on the font package providing those files.

A recent audit run revealed that the number of packages bundling fonts is very high. (repoquery found 159 packages shipping fonts in rawhide, the 2/3rds not being font packages, see bug #477044)

In many case their packagers were not even aware they were bundling fonts (bug #477406#c4). Some of them are licensing problems (477384#c4)

To prevent such problems in the future, rpmlint should flag any package that installs ttf/otf/pfa/pfb fonts outside the %_fontbasedir tree, or bundle those files with binaries in /usr/bin, /usr/lib?? and such.

Packages that include symlinks to files in the %_fontbasedir tree are ok, though they should also get a warning so upstream adds fontconfig support to its code (since it has near universal adoption and continuing to ignore fontconfig will only add to the packager problems in the long run)

http://thread.gmane.org/gmane.comp.freedesktop.xorg/34322/focus=34335
Comment 1 Ville Skyttä 2008-12-22 09:06:17 EST
Both the policy and the implementation (%_fontbasedir) sounds quite Fedora specific and thus the checks would probably be non-upstreamable.  This is not a blocker for inclusion in Fedora's rpmlint, but requires someone to write and maintain the code.  Patches welcome, preferably along with a signup to be a rpmlint co-maintainer to maintain the code.
Comment 2 Nicolas Mailhot 2008-12-22 09:23:29 EST
Even though the macro implementation is currently fedora-specific, it has been split in a self-contained small package with public releases so other distros could pick it up if they liked it.

However, the general problem is just helping packagers to adapt to a fontconfig world, and last I've seen all major distros were standardising on fontconfig (inclusing non-linux ones) so I'd be real surprised if any distribution complained of this check (you can replace %{_fontbasedir} with %{_datadir}/fonts for the general upstream implementation if that makes you feel better)
Comment 3 Ville Skyttä 2008-12-22 10:02:20 EST
It's not about feeling better, macros that don't exist simply cannot be used - even a fallback of not doing anything if it doesn't exist would IMO be impolite arm-twisting other distros into implementing it and rpmlint is not a place for that as far as I'm concerned.  The general trend in upstream rpmlint has been to get rid of any such distro specific things recently.  (BTW I wonder why simply %{_datadir}/fonts was not good enough for the fonts SIG and a new macro (== portability issue) had to be invented.)

If you'd like this to be implemented in upstream rpmlint rather than the Fedora one, feel free to submit an upstream RFE or let me know and I'll do it, and we can close this issue here.  Anyway, if this goes upstream (no matter who submits), please be prepared to take cross distro considerations into account in the request, answer questions and/or present evidence that distros will start adopting something very similar - that way it's much more likely that someone will be interested in implementing it.
Comment 4 Nicolas Mailhot 2008-12-22 10:31:53 EST
(In reply to comment #3)
> (BTW I wonder why
> simply %{_datadir}/fonts was not good enough for the fonts SIG and a new macro
> (== portability issue) had to be invented.)

There was more than a month of public RFC when you could ask such questions (you were one of the handful of people explicitely CC-ed)

But to answer this now:
1. this macro is part of a batch of directory macros,
2. some of the other macros are less obvious, or are pointing to locations upstream is changing
3. using macros means a simple package rebuild once upstream has changed
4. using simple macros means less errors packager-side
5. packagers were all re-defining the same macros in their packages anyway (with twists and subtle mistakes)
6. the macros were explicitely not integrated in a Fedora-specific package but put in a small self-contained package that could be installed or adopted by any interested rpm distro
7. none of the other rpm distros have groups dedicated to fonts packaging or they would have been consulted (the debian and ubuntu folks were)
8. and again, this part is bog-standard fontconfig checking suitable for any fontconfig-enabled distro (the other bits in the fontpackages package may be more Fedora-oriented, even though I've tried to aboid Fedora-isms)
Comment 5 Ville Skyttä 2008-12-23 12:28:55 EST
(In reply to comment #4)
> There was more than a month of public RFC when you could ask such questions
> (you were one of the handful of people explicitely CC-ed)

In the mails that reached my inbox of that thread, I count total of 3 people who provided *any* opinions of the proposal: one voiced "doubt about the usefulness of this", and two others concurred "this sounds like severe overkill".  The brief look I had into the proposal made me firmly agree with those opinions and I was pleased I did not have to dig more deeply into the proposal as several others were already raising the same concerns, and lost interest in the rest of the discussion after that, being (in retrospect, apparently mistakenly) assured that the existing opposition would result in it being cleaned up.

For some reason the proposal was pushed through nevertheless, and now that you're asking people to spend their time adding support for it (without providing code/patches, not only here but in a couple of other bug reports as well), you seem annoyed at me just because I'm pointing out the issues you may run into down that road.  That makes implementing it an even less interesting thing for me personally to consider spending my time on.  Good luck finding others to do it.

Anyway, you did not answer my question in comment 3 but placed a needinfo flag along with comment 4 - what is the info you're looking for, and from whom?
Comment 6 Nicolas Mailhot 2008-12-29 05:56:49 EST
(In reply to comment #5)
> (In reply to comment #4)
> > There was more than a month of public RFC when you could ask such questions
> > (you were one of the handful of people explicitely CC-ed)
> 
> In the mails that reached my inbox of that thread, I count total of 3 people
> who provided *any* opinions of the proposal:

You know how people are. You ask them to comment on public lists, and they comment via PM, non-logged IRC channels or even bugzilla entries :p

Feedback was not limited to three people (for example Behdad whose opinion is critical since he's upstream and downstream for many text components did all his comments in small IRC dialogs)

> For some reason the proposal was pushed through nevertheless,

It was pushed nevertheless because the comments that were expressed were addressed, except for 1 FPC member who was against macros in any form and didn't convince the other FPC members. It's all in the FPC minutes. This is no different from any other FPC/FESCO decision and in fact this proposal was given bigger/longer public exposure than most to give everyone a chance to comment.

There was no way for me to please both people who were rabidly against macros and people who wanted them in, I chose one option and FPC agreed with me.

> and now that
> you're asking people to spend their time adding support for it

I'm asking people to add support since the published plan was always to ask people to add support, no one complained about this part in the long review phase, and FPC/FESCO approved it.

I'm not ashamed on how this stuff was handled, I went above and beyond what is done for most guideline changes (one public multi-week RFC phase in october, first FPC session, another month of public review, test conversion on ~ 30 packages, ~ 12 public releases of the proposed templates, second FPC then FESCO session, full wiki documentation in more than a dozen of different pages, full distro font audit, etc).

This was and still is a ton of work for me and yes, at some point other people in the distro are asked to contribute.
Comment 7 Fedora Admin XMLRPC Client 2010-12-07 16:18:42 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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