Bug 433225 - Review Request: dvipdfmx - A DVI to PDF translator
Review Request: dvipdfmx - A DVI to PDF translator
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Patrice Dumas
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-17 15:28 EST by Jonathan Underwood
Modified: 2008-04-02 21:21 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-07 19:02:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pertusus: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Jonathan Underwood 2008-02-17 15:28:55 EST
Spec URL: http://jgu.fedorapeople.org/dvipdfmx.spec
SRPM URL: http://jgu.fedorapeople.org/dvipdfmx-20071115-1.fc9.src.rpm
Description: The dvipdfmx (formerly dvipdfm-cjk) project provides an eXtended version of the dvipdfm, a DVI to PDF translator developed by Mark A. Wicks.

Commentary: Another package currently part of texlive, for which texlive is not upstream, hence the desire to split it out as a separate package.

dvipdfm seems to be unmaintained, and so dvipdfmx should probably be considered to be upstream for dvipdfm. I note that texlive currently ships both dvipdfm and dvipdfmx. Can we just ship dvipddfxm - does it have all the functionality of dvipdfm?

I have included the cdi-x.map stuff from texlive spec file, but I'm not 100 percent sure this is still needed.

Currently this package obsoletes and provides dvipdfm.
Comment 1 Patrice Dumas 2008-02-17 16:31:17 EST
dvipdfm is not obsoleted by dvipdfmx in my opinion, and still maintained,
last version is from 05.03.2007 which is pretty recent. Both packages
can cohabit.
Comment 2 Jonathan Underwood 2008-02-17 16:43:21 EST
Yeah, there was a minor release in 2007 which incorporated two patches, but no
major development. Before that, last release was 2001. 

I agree that both can co-exist, but what functionality is provided by dvipdfm
that's not in dvipdfmx? If there's good reason, I'll knock up a dvipdfm package,
but if there's no technical reason, I'd rather not bother.
Comment 3 Jonathan Underwood 2008-02-17 16:45:12 EST
But yes, given that both can co-exist, I'll remove the Obsoletes.
Comment 4 Patrice Dumas 2008-02-17 17:06:12 EST
(In reply to comment #2)
> Yeah, there was a minor release in 2007 which incorporated two patches, but no
> major development. Before that, last release was 2001. 

That's not necessarily bad, it may also be that dvipdfm is mature.

> I agree that both can co-exist, but what functionality is provided by dvipdfm
> that's not in dvipdfmx? If there's good reason, I'll knock up a dvipdfm package,
> but if there's no technical reason, I'd rather not bother.

I don't know exactly what you mean by technical reason. In any case
dvipdfm is already in texlive, so maybe it is not worth bothering
packaging it separately if it is not updated more often than texlive.
However I think that a dvipdfm package should stay, especially if it
works well and isn't updated often.
Comment 5 Patrice Dumas 2008-02-17 17:22:10 EST
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

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.

Why the texlive-texmf BuildRequires?

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?

In the texlive spec, there is, for the dvipdfmx subpackage:
# for cmap files
Requires: texlive-texmf-fonts = %{texlive_ver}

I think that it would be better to list explicitly the files
in %_bindir, to avoid surprises.

I suggest adding INSTALL='install -p' to make install.
Comment 6 Jonathan Underwood 2008-02-17 18:09:04 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.
Comment 7 Patrice Dumas 2008-02-17 18:18:10 EST
(In reply to comment #6) 
> 
> > 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?

I am not saying the same. I am saying 0 for the version, and 
x.20071115 for the release.

> > Why the texlive-texmf BuildRequires?
> > 
> 
> For the macro definitions eg. _texmf_main etc.

I think it would be better to define them in case they are
not defined, and this deserves a comment.

> > 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.

Indeed.
 
> > 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.

No, this is only needed if the files come from texlive-texmf-fonts.
Though maybe dvipdfmx needs texlive-texmf-fonts for other reasons.
Comment 8 Jonathan Underwood 2008-02-17 20:24:58 EST
Spec URL: http://jgu.fedorapeople.org/dvipdfmx.spec
SRPM URL: http://jgu.fedorapeople.org/dvipdfmx-0-0.20.20071115cvs.fc9.src.rpm

* Sun Feb 17 2008 Jonathan G. Underwood <jonathan.underwood@gmail.com> -
0-0.20.20071115cvs
- Remove obsolete and Provides for dvipdfm
- Explicitly list contents of bindir in file list
- Fix version and release tags to be guideline conforming
- Add INSTALL='install -p' to make install
- Add macro definitions from texlive-texmf spec file in case not defined
- Remove NEWS and TODO from doc file list
Comment 9 Patrice Dumas 2008-03-03 11:39:23 EST
2 issues remaining:

The 
%{_texmf_main}/fonts/cmap/EUC-UCS2
%{_texmf_main}/fonts/cmap/UniKSCms-UCS2-H
%{_texmf_main}/fonts/cmap/UniKSCms-UCS2-V
files ownership. Jindriiiiiich?

The release is 0.20.... while dvipdfmx coming from current texlive
is 19. It is bad. I suggest using directly 20, even if it is against
the guideline, and use something like
20.1.20071115cvs
to avoid going higher than 20, since dvipdfmx in texlive is already 
wrong. Another possibility would be to use epochs, but I think we should
avoid as much as possible.

Comment 10 Jindrich Novy 2008-03-03 12:24:55 EST
Oops, sorry for a bit delayed reply. I agree to put the latest dvipdfmx in. I
couldn't test the package yet because of broken elfutils in buildroots. I'll
report back later.

For now I can only tell that it is be better to have cmap files shipped in
dvipdfmx than in texlive.
Comment 11 Patrice Dumas 2008-03-03 15:13:21 EST
(In reply to comment #10)

> For now I can only tell that it is be better to have cmap files shipped in
> dvipdfmx than in texlive.

That's the only thing I was waiting for ;-). If you can wait for the 
end of the week I will do the change to texlive needed to remove
dvipdfmx, but if you can do it before, do it.
Comment 12 Jonathan Underwood 2008-03-04 06:49:10 EST
(In reply to comment #9)
> The release is 0.20.... while dvipdfmx coming from current texlive
> is 19. It is bad. I suggest using directly 20, even if it is against
> the guideline, and use something like
> 20.1.20071115cvs
> to avoid going higher than 20, since dvipdfmx in texlive is already 
> wrong. Another possibility would be to use epochs, but I think we should
> avoid as much as possible.

I would much much much rather use an epoch to get around this problem - I think
it's really important to try to stick to the guidelines for version/release tags
since things like automated package rebuild scripts can/will fail for packages
which don't follow the guidelines.
Comment 13 Patrice Dumas 2008-03-04 07:37:13 EST
I really dislike epochs because it is easy to forget about them.
Another possibility would be leave the version as is and not 
add an epoch, and break upgrade paths and tell people
on the devel mailing list to remove the texlive dvipdfmx.

In any case do whatever you prefer between those possibilities.
Comment 14 Jindrich Novy 2008-03-04 10:47:22 EST
(In reply to comment #11)
> (In reply to comment #10)
> 
> > For now I can only tell that it is be better to have cmap files shipped in
> > dvipdfmx than in texlive.
> 
> That's the only thing I was waiting for ;-). If you can wait for the 
> end of the week I will do the change to texlive needed to remove
> dvipdfmx, but if you can do it before, do it.

Ok, dvipdfmx is now remove from texlive-2007-23.fc9 and on. Feel free to
import/build after approval.

FYI: http://koji.fedoraproject.org/koji/taskinfo?taskID=490825
Comment 15 Patrice Dumas 2008-03-06 17:17:32 EST
Since the only remaining issue is up to you, this is 
APPROVED

The source match upstream:
55b30f37da7be24e6a065e286d1f1b2b  dvipdfmx-20071115.tar.gz
Comment 16 Jonathan Underwood 2008-03-06 19:04:47 EST
(In reply to comment #13)
> I really dislike epochs because it is easy to forget about them.

me too.

> Another possibility would be leave the version as is and not 
> add an epoch, and break upgrade paths and tell people
> on the devel mailing list to remove the texlive dvipdfmx.
> 

OK, on balance, I like this option best, so will go with that.

Comment 17 Jonathan Underwood 2008-03-06 19:07:28 EST
New Package CVS Request
=======================
Package Name: dvipdfmx
Short Description: A DVI to PDF translator
Owners: jgu jnovy pertusus
Branches: 
InitialCC: 
Cvsextras Commits: Yes
Comment 18 Kevin Fenzi 2008-03-06 19:22:56 EST
cvs done.
Comment 19 Jonathan Underwood 2008-03-07 19:02:53 EST
Thanks Kevin.

Package built and pushed for rawhide. Closing NEXTRELEASE.
Comment 20 Paul Johnson 2008-04-02 21:21:23 EDT
On Fedora 8, I found texlive-xetex would not install without dvipdfmx, but there
was no such package available.  I downloaded the version from koji and installed
everything OK.  But I think you should put dvipdfmx in the Fedora 8 repository
if you have texlive-xetex require it.

Note You need to log in before you can comment on or make changes to this bug.