[Bug 242416] Review Request: texlive - Binaries for the TeX formatting system

bugzilla at redhat.com bugzilla at redhat.com
Mon Sep 10 20:33:20 UTC 2007


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

Summary: Review Request: texlive - Binaries for the TeX formatting system


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





------- Additional Comments From pertusus at free.fr  2007-09-10 16:33 EST -------
I don't think that
mv %{buildroot}%{_texmf_main}/web2c/*.opt %{buildroot}%{_texmf_conf}/web2c/
for file in `ls %{buildroot}%{_texmf_conf}/web2c/ | egrep 'opt$'`; do
  filename="`basename ${file}`"
  ln -sf %{_texmf_conf}/web2c/${filename} %{buildroot}%{_texmf_main}/web2c/
done

is right. The place where you, as a packager, put config
files should be separated from the place where local
admins put their config, so I think that symlinking is
wrong.

Now regarding which files should be under the sole packager
ruling (ie in %{_datadir}) and which one should be in 
%{_sysconfdir}, I think that it should depend on
* is it something a user should want to change?
  if no, then it is for the packager
* is there something that is likely to change with releases
  if yes it should better be for the packager.

Based on this I think that the following should go 
below %{_sysconfig} (and the remaining remain in usr/share/texmf/):
texmf/dvipdfm/cid-x.map
texmf/web2c/mktexdir.opt
They should be %config(noreplace)

mktexnam.opt and mktex.opt (contrary to what I said above)
should not be in {_sysconfig}, the user in general would better
be if he left those under your control.

Since you moved  kpathsea related programs to main texlive,
you should update the %descriptions 

texhash should certainly be with kpse* binaries.

certainly a miss:
W: texlive dangling-relative-symlink /usr/bin/ovf2ovp omfonts

Maybe one of those isn't in the right package?
W: texlive-fonts dangling-relative-symlink /usr/bin/mktexfmt fmtutil

I guess that the following are right:
W: texlive-latex dangling-relative-symlink /usr/bin/cslatex pdftex
W: texlive-latex dangling-relative-symlink /usr/bin/platex ptex
W: texlive-latex dangling-relative-symlink /usr/bin/pdfplatex-pl pdftex
W: texlive-latex dangling-relative-symlink /usr/bin/platex-pl pdftex
W: texlive-latex dangling-relative-symlink /usr/bin/latex pdftex
W: texlive-latex dangling-relative-symlink /usr/bin/pdfcslatex pdftex
W: texlive-latex dangling-relative-symlink /usr/bin/xelatex xetex
W: texlive-latex dangling-relative-symlink /usr/bin/platex209 ptex
W: texlive-latex dangling-relative-symlink /usr/bin/mllatex pdftex
W: texlive-latex dangling-relative-symlink /usr/share/man/man1/pdflatex.1.gz
pdftex.1.gz
W: texlive-latex dangling-relative-symlink /usr/bin/pdflatex pdftex

Minor issue, there is still a wrong comment about t1lib

In the dvips description: 
* dvips is not only for tex. it is a converter. So I propose 
for 1st sentetence:
Dvips converts .dvi files to PostScript(TM) format.

Or, if you want to mention TeX:
Dvips converts .dvi files, for example those produced by the TeX text 
formatting system, to PostScript(TM) format.

* I think that texlive-afm is not directly useful with dvips and
the mention to texlive-afm should be dropped from dvips.


vfontmap.sample should not be in %{_datadir}/texmf/pxdvi, but
only in %doc. (or in the texmf doc directory).



Regarding the license issues, the files should be removed from the
tarball, like explained on
http://fedoraproject.org/wiki/Packaging/SourceURL
I can do it if you want to.


You didn't took Comment #50 into account, do you want a patch?


And about splitting subpackages that have a distinct upstream, 
adding only what was in tetex and not using the texlive- prefix 
for the packages that should be split, what is your opinion? Just 
tell me if you like some parts, such that I make a patch.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.




More information about the Fedora-package-review mailing list