Bug 427667

CC-ing Matsuura-san.

Spec URL: http://jgu.fedorapeople.org/xdvik.spec
SRPM URL: http://jgu.fedorapeople.org/xdvik-22.84.13-2.fc9.src.rpm

* Sun Jan  13 2008 Jonathan G. Underwood <jonathan.underwood> - 22.84.13-2
- Add patch to build against system kpathsea rather than the one in the tarball
- Same patch also removes all includes to the t1lib headers shipped in the
tarball to 
  prevent conflicts with system t1lib-devel
- Spefile cleanups

Builds fine in mock, doesn't seem to give rpmlint errors or warnings. Therefore,
it's ready for review.

One thing a reviewer might check is where I've put the documentation - it's
unclear if docs should go in /usr/share/doc or /usr/share/texmf/doc. I favour
the former, since that's where docs for all other packages go.

Oh, I should also say, I don't actually have a rawhide installation to check
this runs on, so any testing of the built packages would be much appreciated.

The kpathsea directory was still necessary because of dependencies.
I have sort of fixed it by redoing the dependencies without 
the kpathsea directory, then rerunning configure to use the new 
depend.mk file and last removing the kpathsea directory.

I also made a patch for xdg-open, could you please submit it
upstream?

Also I made other little fixes.

Created attachment 291513 [details]
remove kpathsea directory + minor fcleanups

Created attachment 291514 [details]
add xdg-open to the browsers

(In reply to comment #4)
Thanks for looking it over, Patrice.

> The kpathsea directory was still necessary because of dependencies.
> I have sort of fixed it by redoing the dependencies without 
> the kpathsea directory, then rerunning configure to use the new 
> depend.mk file and last removing the kpathsea directory.
> 

Ah, yes, well spotted, ingenious fix. Don't you love this crufty code :)

> I also made a patch for xdg-open, could you please submit it
> upstream?
> 

Yeah - I'd just fixed that by replaing htmlview with xdg-open, but it's better
to have both there, I agree. Once we've got it all sorted out I plan to send an
email with all of the issues listed - I'll hold off for now to see if we find more.

> Also I made other little fixes.

ok, will check, thanks.

I've given up permitting to use system kpathsea upstream.
The dependencies are computed statically before the build
including and it is too complicated to have it changed in my 
opinion.

Spec URL: http://jgu.fedorapeople.org/xdvik.spec
SRPM URL: http://jgu.fedorapeople.org/xdvik-22.84.13-3.fc9.src.rpm

* Sun Jan  13 2008 Jonathan G. Underwood <jonathan.underwood> - 22.84.13-3
- Added xdg-open patch (Patrice Dumas)
- Avoid dependency generation implicating the bundled kpathsea files (Patrice Dumas)
- Added Requires for Xaw3d

(In reply to comment #8)
> I've given up permitting to use system kpathsea upstream.
> The dependencies are computed statically before the build
> including and it is too complicated to have it changed in my 
> opinion.

Yes, I can quite understand that - I gave up too. I will however describe the
issues we had to deal with to upstream in the hope that will provoke them to
revisit their autotoolery.

Created attachment 291577 [details]
spec file patch fix japanese and minor cleanups

Use bcond for japanese, and fix it.
fix license.
Use update-desktop-database scriptlets everywhere from the 
guidelines.

(In reply to comment #11)

> Use bcond for japanese, and fix it.
> fix license.
> Use update-desktop-database scriptlets everywhere from the 
> guidelines.

Also removed the unneeded Requires that are brought in
automatically.

rpmlint still says:
xdvik.src:17: W: unversioned-explicit-obsoletes xdvi
xdvik.src:18: W: unversioned-explicit-provides xdvi
xdvik.src: W: mixed-use-of-spaces-and-tabs (spaces: line 43, tab: line 5)


Regarding the unversionned obsolete and requires I don't know 
if it is right or not, given that the package name may change
in the future and become xdvi.

Unless somebody else disagrees, and with the patch applied, this is
APPROVED

I'd like to be comaintainer. Jindrich, don't you want too?

OK, thanks Patrice, I'll integrate your patch later when I am home. I didn't
know about bcond, that's very useful. I'll add Patrice and Jindrich as
co-maintainers, unless Jindrich tells me not to.

Not a problem with comaintenance. Thanks Jonathan for packaging xdvi separately!

(In reply to comment #13)
> Regarding the unversionned obsolete and requires I don't know 
> if it is right or not, given that the package name may change
> in the future and become xdvi.
> 

I am inclined to simply change it to 

Provides: xdvi = %{version}-%{release}
Obsoloetes: xdvi < 22.84.12

Objections?

A first note is that it seems to me that 22.84.12 should
be obsoleted (if xdvi is).

The issue I see is that the xdvi package exists and it
is a different upstream. However I can't see a reason why
somebody would want to package it. In fact it may have been 
unfortunate that I (I think it was me in a patch fro 
texlive.spec) called  it xdvi and not xdvik. However it is
not that obvious since it certainly makes sense to have 
yum install xdvi installs xdvik. 

Maybe one possibility could be to drop completely the 
Obsoletes: xdvi

and leave
Provides: xdvi = %{version}-%{release}

This will hurt the rawhide texlive users but maybe it would be
better. Another possiblity could be

Obsoloetes: xdvi = 22.84.12

That way the xdvi in rawhide is obsoleted without much side-effect.

(In reply to comment #17)
> A first note is that it seems to me that 22.84.12 should
> be obsoleted (if xdvi is).
> 

Yes, sorry, I meant Obsoletes: xdvi <=22.84.12

> The issue I see is that the xdvi package exists and it
> is a different upstream. However I can't see a reason why
> somebody would want to package it. 

Yes.. but it's dead upstream ... no release since 2004... xdvik is essentially
upstream now.

> In fact it may have been 
> unfortunate that I (I think it was me in a patch fro 
> texlive.spec) called  it xdvi and not xdvik. However it is
> not that obvious since it certainly makes sense to have 
> yum install xdvi installs xdvik. 
> 

Yes, we definately want yum install xdvi to do the right thing.

> Maybe one possibility could be to drop completely the 
> Obsoletes: xdvi
> 
> and leave
> Provides: xdvi = %{version}-%{release}
> 

I am happy with that...

> This will hurt the rawhide texlive users but maybe it would be
> better. 

I don't think it will, since the xdvi in rawhide is at version 22.84.12-8.fc9,
so rawhide users will just see an updated package. Did I miss something?

On balance i think the last choice is probably best

(In reply to comment #18)
> (In reply to comment #17)
> > A first note is that it seems to me that 22.84.12 should
> > be obsoleted (if xdvi is).
> > 
> 
> Yes, sorry, I meant Obsoletes: xdvi <=22.84.12
> 
> > The issue I see is that the xdvi package exists and it
> > is a different upstream. However I can't see a reason why
> > somebody would want to package it. 
> 
> Yes.. but it's dead upstream ... no release since 2004... xdvik is essentially
> upstream now.
> 

Ooops, I meant xdvi is dead upstream.

(In reply to comment #18)
> (In reply to comment #17)
 
> I don't think it will, since the xdvi in rawhide is at version 22.84.12-8.fc9,
> so rawhide users will just see an updated package. Did I miss something?

Maybe. But I recall strange things happening with real package
names always winning against versioned virtual provides, even 
when the virtual provides is higher.

Anyway, I have tested that without obsoletes,
rpm -Uvh xdvik-22.84.13-3.fc9.i386.rpm
doesn't uninstall xdvi and therefore doesn't proceeds because of
conflicts.

So I guess that the Obsoletes is needed, and I think that
Obsoletes: xdvi = 22.84.12
is the cleanest.

(In reply to comment #20)
> Maybe. But I recall strange things happening with real package
> names always winning against versioned virtual provides, even 
> when the virtual provides is higher.
> 

Hm, ok, that looks like a bug to me.

> Anyway, I have tested that without obsoletes,
> rpm -Uvh xdvik-22.84.13-3.fc9.i386.rpm
> doesn't uninstall xdvi and therefore doesn't proceeds because of
> conflicts.
> 
> So I guess that the Obsoletes is needed, and I think that
> Obsoletes: xdvi = 22.84.12
> is the cleanest.

OK, we'll go with that, simple.

Spec URL: http://jgu.fedorapeople.org/xdvik.spec
SRPM URL: http://jgu.fedorapeople.org/xdvik-22.84.13-4.fc9.src.rpm

* Mon Jan  14 2008 Jonathan G. Underwood <jonathan.underwood> - 22.84.13-4
- Use bcond for Japanese conditional stuff (Patrice Dumas)
- Fix license (Patrice Dumas)
- Make desktop file scriplets conform to packaging guidelines (Patrice Dumas)
- Remove unneeded Requires (Patrice Dumas)
- Adjust Provides and Obsoletes of xdvi

New Package CVS Request
=======================
Package Name: xdvik
Short Description: An X viewer for DVI files
Owners: jgu,pertusus,jnovy
Branches: 
InitialCC: 
Cvsextras Commits: yes

cvs done.

I have added a postun script line without the corresponding

Requires(postun): desktop-file-utils >= %{desktop_file_utils_version}

Thanks Kevin.

Package imported into CVS and successfully built, closing bug.

Jonathan, would you mind if I commit some texlive <-> xdvi adjustments to the
newly imported xdvi?

Sure, go ahead. I did go through the texlive xdvi patches and have included the
ones that still seemed relevant - did I miss some?

The only I added is the fix for temporary files creation in xdvizilla.

I haven't built it yet, so feel free to build it as soon as you think it's ready :)

Unless I am wrong, in your patch you also obsolete every previous
release of xdvi, although we agreed to obsolete only the 
version that went into rawhide... Is it on purpose?

Actually, we also still have a broken upgrade path as well:

# yum --nogpgcheck localinstall xdvik-22.84.13-6.fc9.x86_64.rpm 
Loading "dellsysidplugin" plugin
Loading "fastestmirror" plugin
Setting up Local Package Process
Loading mirror speeds from cached hostfile
 * livna: rpm.livna.org
 * dell-software: linux.dell.com
 * fedora: ftp.linux.org.uk
 * adobe-linux-i386: linuxdownload.adobe.com
 * fwupdate: linux.dell.com
 * updates: ftp.linux.org.uk
Examining xdvik-22.84.13-6.fc9.x86_64.rpm: xdvik - 22.84.13-6.fc9.x86_64
Marking xdvik-22.84.13-6.fc9.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package tetex-xdvi.x86_64 0:3.0-44.3.fc8 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 tetex-xdvi              x86_64     3.0-44.3.fc8     updates           906 k

Transaction Summary
=============================================================================
Install      1 Package(s)         
Update       0 Package(s)         
Remove       0 Package(s)         

Total download size: 906 k
Is this ok [y/N]: y
Downloading Packages:
(1/1): tetex-xdvi-3.0-44. 100% |=========================| 906 kB    00:07     
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test


Transaction Check Error:
  file /usr/bin/pxdvi-xaw3d.bin from install of tetex-xdvi-3.0-44.3.fc8.x86_64
conflicts with file from package xdvi-22.84.12-5.fc9.x86_64
  file /usr/bin/pxdvizilla from install of tetex-xdvi-3.0-44.3.fc8.x86_64
conflicts with file from package xdvi-22.84.12-5.fc9.x86_64
  file /usr/bin/xdvi-xaw3d.bin from install of tetex-xdvi-3.0-44.3.fc8.x86_64
conflicts with file from package xdvi-22.84.12-5.fc9.x86_64
  file /usr/bin/xdvizilla from install of tetex-xdvi-3.0-44.3.fc8.x86_64
conflicts with file from package xdvi-22.84.12-5.fc9.x86_64
  file /usr/share/applications/tetex-xdvi.desktop from install of
tetex-xdvi-3.0-44.3.fc8.x86_64 conflicts with file from package
xdvi-22.84.12-5.fc9.x86_64
  file /usr/share/man/man1/xdvi.1.gz from install of
tetex-xdvi-3.0-44.3.fc8.x86_64 conflicts with file from package
xdvi-22.84.12-5.fc9.x86_64
  file /usr/share/texmf/pxdvi/vfontmap from install of
tetex-xdvi-3.0-44.3.fc8.x86_64 conflicts with file from package
xdvi-22.84.12-5.fc9.x86_64
  file /usr/share/texmf/pxdvi/vfontmap.sample from install of
tetex-xdvi-3.0-44.3.fc8.x86_64 conflicts with file from package
xdvi-22.84.12-5.fc9.x86_64

Error Summary
-------------


It seems the obsoloetes for tetex-xdvi are not working, for reasons that I don't
understand.

Ah, ok, ignore that, I had accidentally disabled the development repo, and had
the F8 repo enabled.

yum --nogpgcheck --enablerepo=development localinstall
xdvik-22.84.13-6.fc9.x86_64.rpm 
Loading "dellsysidplugin" plugin
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
 * livna: rpm.livna.org
 * dell-software: linux.dell.com
 * fedora: ftp.linux.org.uk
 * adobe-linux-i386: linuxdownload.adobe.com
 * development: ftp.heanet.ie
 * fwupdate: linux.dell.com
 * updates: ftp.linux.org.uk
Setting up Local Package Process
Examining xdvik-22.84.13-6.fc9.x86_64.rpm: xdvik - 22.84.13-6.fc9.x86_64
Marking xdvik-22.84.13-6.fc9.x86_64.rpm to be installed
Package xdvi - 22.84.12-9.fc9.x86_64 already installed and latest version
Nothing to do

So, we still aren't obsoleting the old version of xdvi.

My tests show that it works as intended. Both with 
Obsoletes:      xdvi = 22.84.12
Obsoletes:      xdvi < %{version}

Yes, looks like a dep resolving bug with yum when doing localinstall.

(In reply to comment #29)
> The only I added is the fix for temporary files creation in xdvizilla.
> 
> I haven't built it yet, so feel free to build it as soon as you think it's
ready :)

Jindrich, any reason why you extended the obsoletes to cover
< %{version} and not only 22.84.12?

> Jindrich, any reason why you extended the obsoletes to cover
> < %{version} and not only 22.84.12?

I tried to fix the tetex-xdvi obsoletion of the current xdvik, but it apparently
didn't fix the problem.

The problem described in comment #31 is caused by the fact that tetex-xdvi
obsoletes xdvik so that it wants to remove this newly imported xdvik and replace
it by tetex-xdvi when F8 repo is enabled. I'll update/remove the obsoletes on
the tetex side so that this won't happen.

Indeed, this is a good example of unversioned obsoletes being
harmfull...

Yeah, recently I am repeatly seeing the updates message like
=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 tetex-xdvi              i386       3.0-44.3.fc8     koji-8-updates    830 k
     replacing  xdvik.i386 22.84.13-6.fc9

Updating:
 authconfig              i386       5.3.20-1.fc9     koji-rawhide      414 k

Then on next update xdvik obsoletes tetex-xdvi.

(In reply to comment #38)
> The problem described in comment #31 is caused by the fact that tetex-xdvi
> obsoletes xdvik so that it wants to remove this newly imported xdvik and replace
> it by tetex-xdvi when F8 repo is enabled. I'll update/remove the obsoletes on
> the tetex side so that this won't happen.

Ok to set 
Obsoletes:      xdvi = 22.84.12
in xdvik?

(In reply to comment #41)
> Ok to set 
> Obsoletes:      xdvi = 22.84.12
> in xdvik?

It's ok with me.

I commited it. I don't thin k it is worth a rebuild, will appear in next
rebuild anyway.

Package Change Request
======================
Package Name: xdvik
New Branches: el6
Owners: jgu
InitialCC: jnovy pertusus

Git done (by process-git-requests).