Bug 228359 - djvulibre multi-lib conflicts
djvulibre multi-lib conflicts
Product: Fedora
Classification: Fedora
Component: djvulibre (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Matthias Saou
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-02-12 14:58 EST by Michael Schwendt
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-19 11:41:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Schwendt 2007-02-12 14:58:57 EST
djvulibre - 3.5.18-1.fc7.x86_64
  Conflicts: 2
  File conflict in:
  Packages with the same files:
     djvulibre - 3.5.18-1.fc7.i386
Comment 1 Matthias Saou 2007-02-13 05:04:21 EST
Ouch. Is this really to be considered a bug? I really hope not...
Comment 2 Michael Schwendt 2007-02-13 05:45:15 EST
djvulibre-devel.i386 makes available djvulibre.i386 on x86_64.

It's an EasyFix, though.
Comment 3 Matthias Saou 2007-02-13 06:06:00 EST
EasyFix how? I thought rpm had all the hacks it needed to deal with typically
conflicting files like docs, translations and arch-specific binaries in this
kind of case. So if it reports a conflict, the man pages must differ between
arches, right? Is finding out why and finding a solution to make them identical
what you mean by EasyFix?

Maybe I shouldn't have split out the devel sub-package, and stay with the main
package providing it, since AFAIK nothing in Fedora builds against djvulibre
anyway, and the devel is only a few kBs...
Comment 4 Michael Schwendt 2007-02-13 06:20:56 EST
Virtual -devel packages would be no different. All that matters is
that there is a -devel package.

The corresponding thread on fedora-devel-list says that conflicts in
%doc are common. When checking Rawhide, only six packages had a
multi-lib conflict left.

EasyFix, because a single instance of /usr/lib in the manual is
replaced with /usr/lib64. In all other places it still reads /usr/lib
or /usr/local/lib. And "netscape" in the path is inaccurate anyway,
since the file is packaged in a different location.

$ grep /usr/lib nsdejavu.1.x86_64 
.B /usr/lib64/netscape/plugins/nsdejavu.so
.B "/usr/lib/netscape/plugins/nsdejavu.so"
.B "ln -s /usr/lib/netscape/plugins/nsdejavu.so ."
.B "ln -s /usr/lib/netscape/plugins/nsdejavu.so ."
.IR /usr/lib/mozilla-1.1 :
.BI "cd " "/usr/lib/mozilla-1.1" "/plugins"
.B "ln -s /usr/lib/netscape/plugins/nsdejavu.so ."
.IR /usr/lib/mozilla-firefox :
.BI "cd " "/usr/lib/mozilla-firefox" "/plugins"
.B "ln -s /usr/lib/netscape/plugins/nsdejavu.so ."
.B "/usr/lib/netscape/plugins"

$ diff -u nsdejavu.1.i386 nsdejavu.1.x86_64 
--- nsdejavu.1.i386     2007-02-05 13:51:14.000000000 +0100
+++ nsdejavu.1.x86_64   2007-02-05 14:08:18.000000000 +0100
@@ -29,7 +29,7 @@
 nsdejavu \- DjVu browser plugin
-.B /usr/lib/netscape/plugins/nsdejavu.so
+.B /usr/lib64/netscape/plugins/nsdejavu.so
 The shared library
Comment 5 Matthias Saou 2007-02-13 07:08:11 EST
Thanks for the information. I'll include a patch which updates the nsdejavu.1
man page quite a lot, and makes sure it's the same with different LIBDIR values,
as well as a quick one liner for the Japanese man page, since I don't read or
write Japanese...
Comment 6 Matthias Saou 2007-02-13 08:10:52 EST
The patch is ready, but I'll only push a new build once I get bug #186801 fixed
too, since I'm now able to reproduce the problem myself.
Comment 7 Matthias Saou 2007-06-19 11:41:06 EDT
This has been fixed in Rawhide's 3.5.19-2.fc8 package.

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