Bug 426388

Currently, I've just removed evince from the live images, but that seems like a
less than ideal solution

This is fixed in texlive-2007-6 which is now being built.

But kpathsea really depends on telive-fonts. See tex-file.c
init_maketex (format, "mktexfmt", NULL)... or mktexpk
and certainly others
$ rpm -qf /usr/bin/mktexfmt
texlive-2007-5.fc9
$ rpm -qf /usr/bin/mktexpk
texlive-fonts-2007-5.fc9
And unless I am wrong kpathsea work is to run the font related
commands on the font files...

Why does evince depend on kpathsea?

Or, said otherwise, if evince uses kpathsea to create
the fonts it uses, not having tetex-fonts pulled in will 
lead to errors in evince.

Yes, it will. Evince is not able to display dvi files without texlive-fonts. It
seems like we really need to require texlive-fonts or to disable the dvi evince
support for LiveCD.

While looking more into it, to make evince properly work with the dvi support
one needs to install texlive package as well, because of mktexfmt -> fmtutil
with is needed to correctly process fonts if some of them isn't found.

(In reply to comment #6)
> While looking more into it, to make evince properly work with the dvi support
> one needs to install texlive package as well, because of mktexfmt -> fmtutil
> with is needed to correctly process fonts if some of them isn't found.

texlive should be required by the *texmf packages because the post
scripts are in it. In fact it doesn't seems so, which is a bug.
But the situation is complicated because of the build dependency 
of the texlive package on the texmf packages which is quite wrong.
The real issue is that ptex doesn't use fmtutil to generate its
.fmt files, but instead pre-generates them during the build.

In any case the separation between the main texlive package and 
the texlive-fonts package is rather artificial. 

Well, texlive-texmf doesn't need to strictly require binary texlive as all the
stuff in the post scripts is run only in cases the commands exist:

%post
[ -x %{_bindir}/texconfig-sys ] && %{_bindir}/texconfig-sys rehash 2> /dev/null || :
[ -x /sbin/install-info ] && /sbin/install-info %{_infodir}/tds.info.gz
%{_infodir}/dir || :

etc.

to allow to install a different binary tex distro. This is not a bug but
perfectly OK IMO.

BTW. I'm about to merge binary texlive and texlive-fonts subpackages, it should
really be merged, such separation doesn't really have any point for binaries. I
won't merge texlive-texmf-fonts with others of course where a seperation makes
perfectly sense.

(In reply to comment #8)
> Well, texlive-texmf doesn't need to strictly require binary texlive as all the
> stuff in the post scripts is run only in cases the commands exist:
> 
> %post
> [ -x %{_bindir}/texconfig-sys ] && %{_bindir}/texconfig-sys rehash 2>
/dev/null || :
> [ -x /sbin/install-info ] && /sbin/install-info %{_infodir}/tds.info.gz
> %{_infodir}/dir || :
> 
> etc.
> 
> to allow to install a different binary tex distro. This is not a bug but
> perfectly OK IMO.

I don't think it is ok. It means that the .fmt files and the updmap
generated files won't be there at the first install, which is certainly
very wrong.

As for tex distro dependency, what I propose is to have

Requires(post): %{_bindir}/texconfig-sys

%post
%{_bindir}/texconfig-sys rehash 2> /dev/null || :

which is tex distro independent.



> BTW. I'm about to merge binary texlive and texlive-fonts subpackages, it should
> really be merged, such separation doesn't really have any point for binaries. I
> won't merge texlive-texmf-fonts with others of course where a seperation makes
> perfectly sense.

Seems the right thing to do to me too.

Most users will want to read PDFs, so will have evince installed. But almost no
users will want to open DVI files, so a ~80MB dependency makes no sense, either
on the LiveCD or an installed OS.

I think either Fedora should switch DVI support off in evince, or this should be
upstreamed.

Jindrich, if we cannot get kpathsea without dragging in all of texlive,
then I'll turn off dvi support in evince, which would be a shame, imo.
Since it _is_ a nice feature to have on a full installation. But we cannot
have evince pull in 80M of texlive onto the live cd. 

I fully understand that breaking the kpathsea -> texlive dependency will
mean that evince on the live cd will not be able to actually render dvi files 
successfully. 

That is a price I think is worth paying for having dvi support in evince in a
full installation.

But breaking the kpathsea -> texlive dependency may also be
problematic for other software linking against kpathsea
and assuming that the dependencies are right. I guess that
there aren't much of these apps (in general they will require
texlive one way or another), but this is very wrong. Another
solution should be found that doesn't involve removing 
right dependencies.

I don't agree, but its a moot point now. the kpathsea dependency has been moved
to the evince-dvi subpackage, and does not get dragged onto live cds anymore.