Bug 401641 - Add dependency on mkfontdir and mkfontscale: xorg-x11-font-utils
Add dependency on mkfontdir and mkfontscale: xorg-x11-font-utils
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: urw-fonts (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-27 13:54 EST by Terje Røsten
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.4-2.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-28 20:43:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Terje Røsten 2007-11-27 13:54:19 EST
Description of problem:

Original problem is that xfig is not finding fonts it needs. 

This is caused by missing fonts.scale and fonts.dir in 

 {_datadir}/fonts/default/Type1

Which should be created in %post (in urw-fonts package):

%post
{
   umask 133
   mkfontscale %{fontdir} || :
   `which mkfontdir` %{fontdir} || :
   fc-cache %{_datadir}/fonts
} &> /dev/null || :

However mkfontscale and mkfontdir (why the funny `which mkfontdir` thing, btw?) 
is in the xorg-x11-font-utils package which urw-fonts have no requires line to.

Solution: add xorg-x11-font-utils to requires like this:

Requires(post): fontconfig xorg-x11-font-utils

I guess this problem in present in Fedora 7 too.

Thanks!
Comment 1 Nicolas Mailhot 2007-11-27 14:24:31 EST
Please do not suggest solutions contrary to official fonts packaging policy
objectives

http://fedoraproject.org/wiki/PackagingDrafts/FontsPolicy#no-handler-deps

Find a solution that does not require adding deps all over the place, like it's
already the case for the fontconfig part

http://fedoraproject.org/wiki/PackagingDrafts/FontsSpecTemplate
Comment 2 Terje Røsten 2007-11-27 14:54:20 EST
(In reply to comment #1)
> Please do not suggest solutions contrary to official fonts packaging policy
> objectives

Please realise this is not ttf or otf fonts.

If you want to port xfig to fontconfig, be my guest.






  
Comment 3 Terje Røsten 2007-11-27 15:02:26 EST
This is madness, but ok:

So we need a cron job (package) which loops over all fonts dir and creates
fonts.dir and fonts.scale files. Nice. Much better than the old system.

Comment 4 Hans de Goede 2007-11-27 15:52:05 EST
This has been discussed already, see:
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg01730.html

The most simple solution is to just ship pregenerated fonts.dir and fonts.scale
files. This will work as long as the dir in which the fonts reside is not shared
with other packages. I guess its time to add this to the font guidelines.

Alternatively we could fix the font guidelines to drop the bogus demand to not
depend upon xorg-x11-font-utils, xorg-x11-font-utils is very small, and has no
special requires.

And Nicolas, can we please get some more care for core fonts in the font sig, or
otherwise rename it to the fontconfig sig? core fonts are not going to go away,
they are used by Xt and derived toolkits like Xaw, and motif, that adds up to a
lot of apps we are talking about.
Comment 5 Nicolas Mailhot 2007-11-27 16:31:13 EST
(In reply to comment #4)

> Alternatively we could fix the font guidelines to drop the bogus demand 

This is not a bogus demand and works fine for other font backends, and there's
no reason it can not work fine for core fonts.

> And Nicolas, can we please get some more care for core fonts in the font sig,

Core fonts will get as much care in the SIG as core fonts users contribute. It's
a wiki, write autoritative core font scriptlets or guidelines I've said many
times I would welcome them.

What I refuse to do is to do this work in the stead of core font users. I've
paid the "can not find font fixed" price like everyone in the distro for years,
it's time for core font users to start taking care of themselves.

> core fonts are not going to go away,
> they are used by Xt and derived toolkits like Xaw, and motif, that adds up to
> a lot of apps we are talking about.

Then surely there is at least one core font user willing to expend the time to
think about and write core fonts packaging guidelines.
Comment 6 Terje Røsten 2007-11-27 16:39:04 EST
If fonts guys refuse to add xorg-x11-font-utils we could add

Requires(post): xorg-x11-font-utils
Requires: urw-fonts # add more fonts pkgs if needed

and run mkfontscale and mkfontdir in %post section of
xfig-common.








Comment 7 Nicolas Mailhot 2007-11-27 16:41:51 EST
Terje, there are many possible technical solutions, someone just needs to take
responsibility for the core fonts ecosystem, write coherent rules, and get every
package that uses core fonts to respect those rules

Comment 8 Terje Røsten 2007-11-27 18:02:12 EST
Yes, I took the time to read the thread from comment #4, shipping correct fonts.*
files in the first place make most sense.

Comment 9 Hans de Goede 2007-11-28 06:10:50 EST
(In reply to comment #5)
> (In reply to comment #4)
> 
> > Alternatively we could fix the font guidelines to drop the bogus demand 
> 
> This is not a bogus demand and works fine for other font backends, and there's
> no reason it can not work fine for core fonts.
> 

True, it might very well be made to work for core fonts, but, see below ...

> > And Nicolas, can we please get some more care for core fonts in the font sig,
> 
> Core fonts will get as much care in the SIG as core fonts users contribute. It's
> a wiki, write autoritative core font scriptlets or guidelines I've said many
> times I would welcome them.
> 
> What I refuse to do is to do this work in the stead of core font users. I've
> paid the "can not find font fixed" price like everyone in the distro for years,
> it's time for core font users to start taking care of themselves.
> 

The problem is not that you are refusing to work on core font Guidelines, the
problem is that you are actually meddling with Core fonts existing practices in
such a way that core fonts break. If you don't want to touch core fonts, then
don't touch them, including not touching the requires needed for the current
scriplets!

Here is what the font sig has done:
* Create a guildeline that font scriptlets may not have requires

Result:
* Poof core fonts are broken

Here is what the font sig should have done:
* Create guidelines for core font scriptlets so that the requires are no longer
  needed, yet things still work.
* Create a guideline saying that core font scriptlet requires are no longer
  allowed, and that instead the new scriplets should be used.

Result:
* Things stay working

Or alternatively the font sig could have done this:
* Don't make any changes to core fonts as they are fragile, and this means
  keeping the requires for mkfontdir / mkfontscale

Result:
* Things stay working


You (the font sig) have broken things, so now YOU get to fix it. Its really that
simple, everything else is just white noise. If you don't want to fix ti, then
undo the breaking.

Breaking things and then saying yeah we broke it, but we don't care about it so
its not our problem, is not acceptable <period>.



> > core fonts are not going to go away,
> > they are used by Xt and derived toolkits like Xaw, and motif, that adds up to
> > a lot of apps we are talking about.
> 
> Then surely there is at least one core font user willing to expend the time to
> think about and write core fonts packaging guidelines.
> 

Perhaps, but right now the font sig is doing things backwards, YOU are actively
causing breakage, while you should have waited / worked in guidelines instead of
just breaking things. YOU are causing regressions, stop doing that please.
Comment 10 Nicolas Mailhot 2007-11-28 07:32:11 EST
(In reply to comment #9)
> (In reply to comment #5)
> > (In reply to comment #4)

> > > And Nicolas, can we please get some more care for core fonts in the font sig,
> > 
> > Core fonts will get as much care in the SIG as core fonts users contribute. It's
> > a wiki, write autoritative core font scriptlets or guidelines I've said many
> > times I would welcome them.
> > 
> > What I refuse to do is to do this work in the stead of core font users. I've
> > paid the "can not find font fixed" price like everyone in the distro for years,
> > it's time for core font users to start taking care of themselves.
> > 
> 
> The problem is not that you are refusing to work on core font Guidelines, the
> problem is that you are actually meddling with Core fonts existing practices in
> such a way that core fonts break.

Please look at changelogs dates, this particular package (and all the broken
core font packages we have right now) was modified before I even launched the
Font SIG idea. I didn't break anything. I didn't touch this package. It would be
broken the same way if I hadn't done any font work. Now people find out core
fonts are broken, I only ask they find clean solutions that do not clash with
what we've done for other font systems, and document them so we don't hit the
same problems in 20 different packages.

Core font users are used to the comfortable position where someone else fixes
their problems for them. Big news: core font system is not critical enough
anymore for this to happen. Stop complaining about the SIG the SIG didn't break
anything, core fonts basically broke because no one was caring enough anymore to
write good guidelines and check they actually work. The fix is to actually step
up to write the guidelines, not rant about the SIG in bugs.
Comment 11 Ngo Than 2007-11-28 08:10:36 EST
in my opinion, it isn't a good idea to ship pregenerated fonts.dir and 
fonts.scale in urw-fonts. Adding requires on xorg-x11-font-utils is the clean 
solution for me.
Comment 12 Ngo Than 2007-11-28 08:25:57 EST
the problem is only affected in F8 and new
Comment 13 Hans de Goede 2007-11-28 08:47:32 EST
(In reply to comment #11)
> in my opinion, it isn't a good idea to ship pregenerated fonts.dir and 
> fonts.scale in urw-fonts. Adding requires on xorg-x11-font-utils is the clean 
> solution for me.

Agreed, lets do that then (as many core fonts packages still do) and close this
bug. I think since many people will have this problem without knowing it this
warrants an F-8 update (besides fixing this in devel).

As for this being against the new fonts guidelines, the new guidelines are
broken in that they do not offer a solution to the problem this creates, so I
say ignore them until this bug in the guidelines gets fixed.
Comment 14 Nicolas Mailhot 2007-11-28 09:15:37 EST
(In reply to comment #13)

> As for this being against the new fonts guidelines, the new guidelines are
> broken in that they do not offer a solution to the problem this creates,

The new guidelines are not broken. They don't offer a solution but don't prevent
every solution either. You know that perfectly well.

I only ask you to respect the work of other project members and try to fit in.
If you prefer to knowingly make quick and dirty antisocial choices rather than:
1. think 10 min
2. do the missing documentation work (on a subsystem you've just claimed is
highly critical for you)
That's pretty sad, and will end up in ugly clashes.

And I don't even ask an apology for your wild claims I broke this package, or
all the other core fonts packages that passed all F8 test releases without one
core fonts user bothering to test them and report problems.
Comment 15 Hans de Goede 2007-11-28 11:05:54 EST
(In reply to comment #14)
> (In reply to comment #13)
> 
> > As for this being against the new fonts guidelines, the new guidelines are
> > broken in that they do not offer a solution to the problem this creates,
> 
> The new guidelines are not broken. They don't offer a solution but don't prevent
> every solution either. You know that perfectly well.
> 

By requiring the removal of Requires on mkfontdir and mkfontscale and not giving
a solution for the problems this creates, they are causing this breakage, or in
this case since appearantly the Requires were removed before the guidelines they
are stopping this problem from getting fixed.

> I only ask you to respect the work of other project members and try to fit in.
> If you prefer to knowingly make quick and dirty antisocial choices rather than:
> 1. think 10 min
> 2. do the missing documentation work (on a subsystem you've just claimed is
> highly critical for you)
> That's pretty sad, and will end up in ugly clashes.
> 

Whats antisocial about adding a single innocent requires? Why must font packages
not have this requires? If not having those requires is so important to some,
isn't it up to those some to come up with fixes for the problems this creates?

> And I don't even ask an apology for your wild claims I broke this package, or
> all the other core fonts packages that passed all F8 test releases without one
> core fonts user bothering to test them and report problems.

No problems were reported because most test release users update from previous
releases thus avoiding the problem, just because it didn't get reported earlier
doesn't mean its not a problem.

And I do apology, as I've just re-read the font guidelines as written here:
http://fedoraproject.org/wiki/SIGs/Fonts/Packaging/Policy

And I was wrong, they only disallow Requires on mkfontdir / mkfontscale for
"non-legacy format (TTF or OTF)" fonts, so they do not apply to urw-fonts, nor
to any fonts installed by default as core fonts. So the solution for this is
really simple, just readd the Requires(post): mkfontdir and mkfontscale, and all
is well.

Than can you do that please, and preferably make this an F-8 update as well?
Thanks!

Comment 16 Ngo Than 2007-11-28 11:44:27 EST
it's already built in F8-update tree and will be pushed today or tomorrow
Comment 17 Terje Røsten 2007-11-28 12:49:12 EST
> it's already built in F8-update tree and will be pushed today or tomorrow

Thanks Than!
Comment 18 Fedora Update System 2007-11-28 20:43:52 EST
urw-fonts-2.4-2.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

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