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: dvipdfmx - A DVI to PDF translator
https://bugzilla.redhat.com/show_bug.cgi?id=433225
------- Additional Comments From jonathan.underwood(a)gmail.com 2008-02-17 18:09 EST
-------
(In reply to comment #5)
rpmlint says:
dvipdfmx.src: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 9)
dvipdfmx.i386: E: zero-length /usr/share/doc/dvipdfmx-20071115/NEWS
OK, will fix.
It seems to me that version should be 0 and release should be
0.x.20071115. However, dvipdfmx in texlive is already at release 16, so
it seems to me that it can be
17.x.20071115. Or even x.20071115 with x beginning at 17.
Well, here I'd agree we should have something like x.20071115 as the version
number, but I don't like the 17 - what happens when upstream get to 1.0 for
example. This seems like a legitimate use of epoch to me. What do you think?
Why the texlive-texmf BuildRequires?
For the macro definitions eg. _texmf_main etc.
The files
%{_texmf_main}/fonts/cmap/EUC-UCS2
%{_texmf_main}/fonts/cmap/UniKSCms-UCS2-H
%{_texmf_main}/fonts/cmap/UniKSCms-UCS2-V
are already owned by texlive-texmf-fonts, which package should own them?
I think these should be in the dvipdfmx package, as they originate from that
tarball - will wait for Jindrich to comment on this also.
In the texlive spec, there is, for the dvipdfmx subpackage:
# for cmap files
Requires: texlive-texmf-fonts = %{texlive_ver}
Yes, I can do that in this package also.
I think that it would be better to list explicitly the files
in %_bindir, to avoid surprises.
OK.
I suggest adding INSTALL='install -p' to make install.
OK. Can't help wondering why this isn't a guideline.
--
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.