Hello Jindrich,
Thoughts below..
On 26 January 2013 17:41, Jindrich Novy <jnovy@xxxxxxxxxx> wrote:
[snip]
>> With the more fine grained texlive packaging in F>18 where tex(latex) is
>> provided by texlive-collection-latex I am finding that this is insufficient
>> to build most documents. I see two options in these cases:
>>
>> 1) Add BuildRequires; texlive-collection-latexextra (nb.
>> texlive-collection-latexrecommended isn't usually sufficient)
>>
>> 2) Generate a list of specific style files using an incantation such as
>>
>> egrep -R 'usepackage|documentclass|RequirePackage' * | cut -d']' -f2 | cut
>> -s -d'{' -f 2 | sed s/"}"/.sty"}"/g | cut -d'}' -f1 | sort | uniq
>>
>> and turn this into a list of specific BuildRequires: tex(foo.sty) lines.
[snip]
> the purpose of tex(*) virtual provides is to make a TeX feature
> available regardlessly on TeX distribution available (texlive, miktex,
> tetex, etc.) in Fedora.
Yes, the tex(live) virtual provides was something I think I suggested
back in the old days of the switch from tetex to texlive. The idea was
that tex(latex) would pull in enough of a LaTeX environment to build
most documents i.e. those using the basic LaTeX styles (article, book,
etc). That's what it did for tetex, and for the old texlive 2007
packaging. With texlive 2012 packaging you've repurposed tex(latex) to
mean "a minimal latex install" (without class files and fonts), and
this has left a lot of packages in the FTBFS state. I personally think
tex(latex) should bring in enough to build documents that use the
standard LaTeX styles and also the standard fonts.
> From this POV (1) doesn't seem to be an
> optimal
> solution because:
>
> * your package will be dependend on texlive TeX distro
This part isn't true - whichever route we go, the package will Require
tex(latex) which will be provided by whatever tex distribution is
packaged. Nothing changed in this regard.
> * you are going to pull in tons of dependencies you don't actually
> need
>
Yes, this is the trade off. We'll end up with more style files and
fonts installed in the buildroot than are actually used. But that's
the way it was with the texlive 2007 packages. The advantage is we
don't have to have 20 or so BuildRequires in every spec file requiring
LaTeX.
> Every TeX package contains virtual provides of:
> ".tfm", ".ttf", ".ttc", ".pfa", ".pfb", ".pcf",
> ".otf", ".tex", ".cnf", ".cfg", ".def", ".dat",
> ".ldf", ".fd", ".enc", ".map", ".vf", ".vpl",
> ".clo", ".bug", ".bg2", ".cbx", ".bbx", ".cls", ".sty"
> files if it ships any of file of such an extension. So the process of
> "my tex file doesn't compile" should be addressed like this:
>
> a) figure out which file is missing - (La)TeX is quite explicit about
> this in error logs
> b) install tex(<file>.<extension>) and add the BR to package
> c) does it compile now? No = go to a)
> d) done
>
The problem is, this is time consuming, and will break package
building anytime a new version uses a new latex style file (package),
increasing the burden of package maintainership. I think this may
result in people just turning of the building of documentation in
their package (I have been tempted).
> The tex(tex), tex(latex), etc. dependencies are here to cover
> minimalistic, most frequently used styles to reduce the amount of
> manual work.
This is the crux of it: what qualifies as "most frequently used
styles" - the definition has been changed with the new packaging with
the result that more BuildRequires are needed for packages.
Presently the tex(latex) virtual provide isn't actually of much
utility - alone it's usually not sufficient. Adding BuildRequires on a
style file will pull in the needed texlive-base etc anyway. So, this
is why I think we should consider making the tex(latex) virtual
provides more encompassing and useful to help packkagers.
I understand that the most "correct" way is a long list of explicit
BRs for individual styles files and needed fonts, and I do see the
technical appeal of that. But, I also think we could probably be a bit
more pragmatic with the tex(latex) virtual provide.
Cheers,
Jonathan.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
