[Bug 438006] After `yum install vnc-server' firefox does not run

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: After `yum install vnc-server' firefox does not run


https://bugzilla.redhat.com/show_bug.cgi?id=438006





------- Additional Comments From nicolas.mailhot at laposte.net  2008-03-18 16:42 EST -------
(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.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.