Bug 228359
| Summary: | djvulibre multi-lib conflicts | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Schwendt <bugs.michael> |
| Component: | djvulibre | Assignee: | Matthias Saou <matthias> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-06-19 15:41:06 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Ouch. Is this really to be considered a bug? I really hope not... djvulibre-devel.i386 makes available djvulibre.i386 on x86_64. It's an EasyFix, though. 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... 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 .SH SYNOPSIS -.B /usr/lib/netscape/plugins/nsdejavu.so +.B /usr/lib64/netscape/plugins/nsdejavu.so .SH DESCRIPTION The shared library 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... 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. This has been fixed in Rawhide's 3.5.19-2.fc8 package. |
djvulibre - 3.5.18-1.fc7.x86_64 Conflicts: 2 File conflict in: /usr/share/man/man1/nsdejavu.1.gz /usr/share/man/ja/man1/nsdejavu.1.gz Packages with the same files: djvulibre - 3.5.18-1.fc7.i386