Bug 228171 - multi-lib conflict
Summary: multi-lib conflict
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: hspell   
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Dan Kenigsberg
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 228170 (view as bug list)
Depends On:
Blocks: FE7Target
TreeView+ depends on / blocked
 
Reported: 2007-02-10 23:26 UTC by Michael Schwendt
Modified: 2007-11-30 22:11 UTC (History)
0 users

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


Attachments (Terms of Use)

Description Michael Schwendt 2007-02-10 23:26:55 UTC
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?

Comment 1 Michael Schwendt 2007-02-10 23:28:12 UTC
*** Bug 228170 has been marked as a duplicate of this bug. ***

Comment 2 Dan Kenigsberg 2007-02-11 07:01:54 UTC
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.

Comment 3 Dan Kenigsberg 2007-02-11 07:11:09 UTC
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


Comment 4 Michael Schwendt 2007-02-11 11:22:37 UTC
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.


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