Bug 237171 - Multiple packaging flaws in bi-arch installations
Multiple packaging flaws in bi-arch installations
Status: CLOSED DUPLICATE of bug 426672
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Panu Matilainen
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-19 16:08 EDT by Kevin Graham
Modified: 2009-10-06 01:14 EDT (History)
3 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Kevin Graham 2007-04-19 16:08:11 EDT
Description of problem:

With "bi-arch" or "multilib" installs of x86_64/i386, there are an arms-length
of conflicts, even on a relatively limited install. In many cases, these are
just modtimes, however they are useful for illustrating the problem. Due to
this, not even the glibc or selinux packages pass verification. This is similar
to issue 235757 and issue 228358, however neither seems to address the root
packaging flaws.

Version-Release number of selected component (if applicable):

RH5.x, RH4.x

How reproducible:

 # rpm -q libselinux --queryformat '%{NAME} %{VERSION} %{ARCH}\n'
libselinux 1.33.4 i386
libselinux 1.33.4 x86_64
# rpm --verify libselinux
S.5....T   /usr/sbin/avcstat
S.5....T   /usr/sbin/getenforce
S.5....T   /usr/sbin/getsebool
S.5....T   /usr/sbin/matchpathcon
S.5....T   /usr/sbin/selinuxenabled
S.5....T   /usr/sbin/setenforce
S.5....T   /usr/sbin/togglesebool
.......T d /usr/share/man/man8/avcstat.8.gz
.......T d /usr/share/man/man8/booleans.8.gz
.......T d /usr/share/man/man8/getenforce.8.gz
.......T d /usr/share/man/man8/getsebool.8.gz
.......T d /usr/share/man/man8/matchpathcon.8.gz
.......T d /usr/share/man/man8/selinux.8.gz
.......T d /usr/share/man/man8/selinuxenabled.8.gz
.......T d /usr/share/man/man8/setenforce.8.gz
.......T d /usr/share/man/man8/togglesebool.8.gz

# rpm -q ncurses --queryformat '%{NAME} %{VERSION} %{ARCH}\n'
ncurses 5.5 x86_64
ncurses 5.5 i386
# rpm --verify ncurses  | tail -5
prelink: /usr/bin/clear: at least one of file's dependencies has changed since
prelinking
prelink: /usr/bin/infocmp: at least one of file's dependencies has changed since
prelinking
prelink: /usr/bin/tack: at least one of file's dependencies has changed since
prelinking
prelink: /usr/bin/tic: at least one of file's dependencies has changed since
prelinking
prelink: /usr/bin/toe: at least one of file's dependencies has changed since
prelinking
prelink: /usr/bin/tput: at least one of file's dependencies has changed since
prelinking
prelink: /usr/bin/tset: at least one of file's dependencies has changed since
prelinking
.......T   /usr/share/terminfo/z/zenith39-ansi
.......T   /usr/share/terminfo/z/zt-1
.......T   /usr/share/terminfo/z/ztx
.......T   /usr/share/terminfo/z/ztx-1-a
.......T   /usr/share/terminfo/z/ztx11
# 


Expected results:

That a freshly installed machine wouldn't have over 3000 files reported as
inconsistent by an 'rpm --verify'.

Additional Info:

For most of the ncurses case (as well as parted, pam, libX11), this suggests the
need for a dependent 'noarch' packages, whereas others (ie. pam) would need
separate 'doc' or 'man' packages. If files are identical across architectures
then they don't belong in an architecture-specific package; at the minimum this
would apply to packages that would be installed in a biarch/multilib
installation (ie. this can't be extended too far, as things like daemon init
scripts would lead to package count explosions).
Comment 1 Jeff Johnson 2007-05-01 10:59:14 EDT
Adding --nomtime will prevent displaying files that are different solely because of st_mtime.

The executables that differ in size and md5 digest should be in a different state.

Could you check the output of "rpm -qs libselinux" and make sure that, indeed, the executables
that differ with size/md5 are in a non-installed state?

The real fix will be in rpm --verify, to not produce output under the 2 conditions described above.
Comment 2 Kevin Graham 2007-05-01 20:08:45 EDT
> Adding --nomtime will prevent displaying files that are different
> solely because of st_mtime.

Of course. However, its useful to illustrate what are errors in packaging. If
the files are identical in every regard but st_mtime, then they shouldn't be
bundled in both i386 and x86_64 packages (for that matter, rpm should've refused
to install them).

In the case of ncurses from comment 0, terminfo definitions belong in a separate
noarch package.

With regards to 

$ rpm -qs libselinux | sort | uniq -c
      1 normal        /lib/libselinux.so.1
      1 normal        /lib64/libselinux.so.1
      1 normal        /usr/lib/libselinux.so
      1 normal        /usr/lib64/libselinux.so
      2 normal        /usr/sbin/avcstat
      2 normal        /usr/sbin/getenforce
      2 normal        /usr/sbin/getsebool
      2 normal        /usr/sbin/matchpathcon
      2 normal        /usr/sbin/selinuxenabled
      2 normal        /usr/sbin/setenforce
      2 normal        /usr/sbin/togglesebool
      2 normal        /usr/share/man/man8/avcstat.8.gz
      2 normal        /usr/share/man/man8/booleans.8.gz
      2 normal        /usr/share/man/man8/getenforce.8.gz
      2 normal        /usr/share/man/man8/getsebool.8.gz
      2 normal        /usr/share/man/man8/matchpathcon.8.gz
      2 normal        /usr/share/man/man8/selinux.8.gz
      2 normal        /usr/share/man/man8/selinuxenabled.8.gz
      2 normal        /usr/share/man/man8/setenforce.8.gz
      2 normal        /usr/share/man/man8/togglesebool.8.gz
      2 normal        /var/run/setrans
$


> The real fix will be in rpm --verify, to not produce output under
> the 2 conditions described above.

From the looks of the output above, there's nothing broken with rpm --verify
that needs to be fixed for the purposes of this issue. In fact, the only
potential issue with rpm at all is that these files were installed in the first
place.

To keep this bug from creeping beyond its original intent, the issue I would
like addressed here is what was described in 'Additional Info' of comment 0 --
there are quite a few packages that are targeted for biarch installs that have
conflicting executables and supporting files represented in both the i386 and
x86_64 packages. This is a flaw in the packages, not the package manager.
Comment 3 Jeff Johnson 2007-05-05 11:53:30 EDT
Yes. the packages were misbuilt.

The *.gz man pages differ because not re-compressed with gzip -n, which
would remove the timestamp that is the only difference between elf32/elf64 packages.

The executables are elf64, which is consistent with rpm's install policy
   Always prefer elf64.

The libraries are on different paths, and so do not conflict.

Since the packages were all built on a possibly misconfigured build system (i.e. no gzip -n if man pages
are displayed as changed by --verify), the only rpm fix possible is in --verify.

rpm is certainly not responsible for how RH chooses to build and ship packages.
Comment 4 Kevin Graham 2007-07-17 12:10:15 EDT
I have since been unable to reproduce this and my best guess is that it can be
attributed to a broken yum repo that had newer versions of only i386 packages
without their x86_64 counterparts. Likewise this can probably be closed out as a
stupid-user-trick.

Jeff -- before we NOTABUG this, would you care to weigh in on how RPM should
address this? The install policies you described in comment 3 make sense, but
should versions be preferred over architectures?
Comment 6 Jeremy West 2009-10-06 01:14:19 EDT

*** This bug has been marked as a duplicate of bug 426672 ***

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