Bug 438006

Save yourself pain and on any box you want to be able to display X apps, just
yum groupinstall base-x

(In reply to comment #1)
> Save yourself pain and on any box you want to be able to display X apps, just
> yum groupinstall base-x

While thanks for the advice groupinstall is only a workaround.  The rpm
dependencies should ensure the application can start in its minimal form after
being installed.

Been there done that.  Unfortunately, it's not as simple as that.

How to distinguish between deps required for a functional X server (base-x) or X
clients?

Hmm, I now see the server-client distinction, thanks.
`vnc-server' is just the server-side but `firefox' is just the client side.
And `fontconfig' uses client-side fonts (while `X' uses server-side fonts).

Suggesting:
  fontconfig: Requires: xorg-x11-fonts-base-client
  xorg-x11-fonts-Type1: Provides: xorg-x11-fonts-base-client
  xorg-x11-fonts-truetype: Provides: xorg-x11-fonts-base-client
  (possibly other fonts)

disadvantage: If I want just to --rebuild an application using fontconfig
  without running it I will nonetheless wastefully need some client-side font.

advantage: All the applications can remain the same.  Some right solution would
  need to add:
  EACH-fontconfig-using-application: Requires: xorg-x11-fonts-base-client

Rex, do you agree?  To reassign it to the Package `fontconfig'.

shrug, looks like a start toward something less broken than the status-quo
anyway. :)

fontconfig: Is there a go for the Comment 4 dependencies?

(In reply to comment #4)
> Hmm, I now see the server-client distinction, thanks.
> `vnc-server' is just the server-side but `firefox' is just the client side.
> And `fontconfig' uses client-side fonts (while `X' uses server-side fonts).
> 
> Suggesting:
>   fontconfig: Requires: xorg-x11-fonts-base-client
>   xorg-x11-fonts-Type1: Provides: xorg-x11-fonts-base-client
>   xorg-x11-fonts-truetype: Provides: xorg-x11-fonts-base-client
>   (possibly other fonts)

Unfortunately the xorg-x11-fonts-* are the last packages you want on a font
config system. They're old fonts with lots of problems

Now if you do start requiring font packages you're in for a big mess because
1. you can't require specific font packages. Users of font A don't want to be
forced to install font B esp if font B prio is higher in fontconfig and will
mask font A.
2. you can't require a single font package. You need to require enough fonts to
cover our i18n needs.
3. Every font package has its own coverage, and coverage overlaps. You can't
easily substitute an (A,B,C) font combo by a (D,E,F) one — A will have a
different coverage than D, B a different coverage than E, etc
4. Besides coverage changes with font versions, and is generally not something
you can track by hand.
5. even if you could identify font package coverage automatically, just because
a font includes an unicode block does not mean it's rendering of this unicode
block is suitable.
5. the fedora font offering is changing over time and managing font deps by hand
in other packages is going to be loads of fun.
6. every app can not handle every font format

My conclusion would be to "just say no". We don't require all the bits needed
for a base system, we assume the base system is present. Fine-grained tracking
is not worth it. I don't think fine-grained font deps are worth it either. When
in doubt just install the default/mandatory packages in the fonts group of the
day. If needed we'll create a base-fonts group. But there's no way I'll start
playing the manual synthetic provides game in font packages (and I maintain a
few of the most used ones).

So the solutions are:
1. do nothing. Teach users of hand-rolled minimal installs fonts are declared in
the fonts group
2. roll a base-fonts group if for some reason the fonts group is not
appropriate. Probably requires going before FESCO to approve a change in the
fonts comps policy it reviewed last year.
3. have someone write an font-auto-provides script that:
  A. examines files installed in /usr/share/fonts
  B. determines their format
  C. adds synthetic font(unicode_block) font(script) font(format,unicode_block)
font(format,script) autoprovides (based on latest unicode spec and fontconfig
script tables)
  D. includes a way for packagers to remove a script or unicode block from
provides if this part of the font sucks, or blacklist the whole font it it's an
artistic font not intended for everyday text
  E. and then add the corresponding requires to packages in need (people will
still complain your autoprovides show no style taste)

3. is the only complete solution but is a lot of work. Good luck finding someone
to tackle it. 1. or 2. will probably be judged insufficient by the reporter. I
refuse to even consider the xorg-x11-fonts-base-client as it'd be a lot of work
packaging side, without providing a satisfying solution for a large part of our
user base.

I spent half of last Sunday reviewing all the F9-targeted font packages and
fixing the fonts part of the F9 comps file, so I have a pretty good idea where
we stand right now. And if I had more time I'd work on the huge fonts packaging
wishlist backlog instead of worrying about this kind of corner case.

We should make clear what was the original problem I submitted this Bug:
-> Firefox does not start at all.

In fact I do not care much of the cosmetic aspects of the application(s) in some
testing environment.  US-ASCII in monospace is perfectly fine for me in such
case.  I also do not care of any weird non-English languages (speaking natively
non-English).

Debian has "required" packages and "suggested" packages.  RPM does not make this
difference and the RPM "Requires" is there only for the "required" packages. You
are describing more the "suggested" packages (fonts) set and possibly even more.

Your intentions may be right but they are out of the scope of this Bug.

Your 1.(problem) is covered by the `xorg-x11-fonts-base-client' virtual
dependency.  If I have any client (fontconfig compatible) font nothing gets
installed.  If there is no fontconfig font some random one will be installed
(and I do not care which one as any real end-user system will have enough of
them by default).

Your 2.+3.+5.(problems) talks about non-ASCII issues, these fonts are not
requires for a basic start of an application.

Your 4.(problem) - the Provides of `xorg-x11-fonts-base-client' should be placed
into several (those 2 in my Comment 4?) fontconfig-compatible fonts and it will
not change in the future.

Your 6.(problem) I do not understand - we are talking about ASCII-compatible
fontconfig-compatible fonts here.

Your 1.+2.(solution) does not solve the problem I posted.

Your 3.(solution) is an excessive workload out of the scope of this Bug.

I am not an artist and the problem I posted will never be faced by any regular
end-user.  It is faced by the QA folks and the developers.  I usually even do
not see the application started as I just login there by text SSH and anyway my
link is too slow to (needlessly) run a VNC viewer over it.

Sorry I still see my Comment 4 as the optimal solution for the simple problem
posted.

(In reply to comment #8)
> We should make clear what was the original problem I submitted this Bug:
> -> Firefox does not start at all.
> 
> In fact I do not care much of the cosmetic aspects of the application(s) in some
> testing environment.  US-ASCII in monospace is perfectly fine for me in such
> case.

But we care. If you ask us to do impacting changes, they must solve more than
your own little corner case.

(In reply to comment #9)
> (In reply to comment #8)
> > We should make clear what was the original problem I submitted this Bug:
> > -> Firefox does not start at all.
> > 
> > In fact I do not care much of the cosmetic aspects of the application(s) in some
> > testing environment.  US-ASCII in monospace is perfectly fine for me in such
> > case.
> 
> But we care. If you ask us to do impacting changes, they must solve more than
> your own little corner case.

On any real end-user system: The suggested dependency is always satisfied
multiple times, no behavior change happens.

On minimal system with only installed X server: Firefox (and other apps) starts
with (some ugly?) font instead of silently refusing to start. Also one random
font package gets installed in such case.

Feel free to close the bug if the suggested change makes it worse.

There's a bug open about making fontconfig require fonts-latin, and fonts-latin
will be provided by all Latin font packages.  Something like that...

*** This bug has been marked as a duplicate of 257901 ***