Bug 228171
| Summary: | multi-lib conflict | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael Schwendt <bugs.michael> |
| Component: | hspell | Assignee: | Dan Kenigsberg <danken> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | hspell-1.0-6.fc7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-04-01 19:00:07 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 213321 | ||
*** Bug 228170 has been marked as a duplicate of this bug. *** I compared the two directories and noticed that the difference is only in one character per file: /tmp/h$ hexdump i386/hebrew.wgz|head -1 0000000 8b1f 0008 c96c 44b0 0302 5dcc 9adb baa2 /tmp/h$ hexdump 64/hebrew.wgz|head -1 0000000 8b1f 0008 c981 44b0 0302 5dcc 9adb baa2 both files decompress well in both architectures. could it be that the gzip produces a different file (different magic number?) according to its architecture? P.S. I don't know what multi-lib is, and what is the relevance of this bug's name. Taking a look at RFC 1952 (GZIP File Format) http://www.gzip.org/zlib/rfc-gzip.html , I understand that the differing 5th character is part of the Modification Time of the original file. I suspect that the reason for the difference is that the two RPMs are packaged in different times: ls --full-time 64/h i386/h -rw-r--r-- 1 danken danken 1026227 2007-02-11 09:05:23.000000000 +0200 64/h -rw-r--r-- 1 danken danken 1026227 2007-02-11 09:05:58.000000000 +0200 i386/h The file could be compressed with option -n to be the same.
> P.S. I don't know what multi-lib is, and what is the
> relevance of this bug's name.
multi-lib is the concept that makes it possible to install libraries
built for a compatible hardware architecture alongside the libraries
for the native hardware, because both can used by corresponding
executables. For example, on x86_64 the native libs are installed
into /usr/lib64, while the compatible ix86 libs are installed into
/usr/lib. That is the reason why %_libdir expands to different values
on these systems. This also makes it possible to build ix86 binaries
on a x86_64 systems, because you only need to tell the compiler which
architecture to build for and install the needed -devel packages for
that architecture. Due to that, ix86 -devel rpms and their dependencies
are made available in the x86_64 repository.
In the context of this ticket, users of x86_64 hardware, who want to
or need to install hspell for i386 (as a dependency of some i386 rpms),
could not have hspell for x86_64 installed already, since both packages
conflict in these data files.
|
hspell - 1.0-4.fc6.i386 Conflicts: 8 File conflict in: /usr/bin/hspell /usr/share/hspell/hebrew.wgz /usr/share/hspell/hebrew.wgz.prefixes /usr/share/hspell/hebrew.wgz.desc /usr/share/hspell/hebrew.wgz.stems Packages with the same files: hspell - 1.0-4.fc6.x86_64 The files in /usr/share ought to be arch-independent. Why do they differ between i386 and x86_64?