Bug 433225

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.

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.

But yes, given that both can co-exist, I'll remove the Obsoletes.

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

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.

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

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

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

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.

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.

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

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

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.

(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

Since the only remaining issue is up to you, this is 
APPROVED

The source match upstream:
55b30f37da7be24e6a065e286d1f1b2b  dvipdfmx-20071115.tar.gz

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

New Package CVS Request
=======================
Package Name: dvipdfmx
Short Description: A DVI to PDF translator
Owners: jgu jnovy pertusus
Branches: 
InitialCC: 
Cvsextras Commits: Yes

cvs done.

Thanks Kevin.

Package built and pushed for rawhide. Closing NEXTRELEASE.

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.