Bug 237171
| Summary: | Multiple packaging flaws in bi-arch installations | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Kevin Graham <kgraham> |
| Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | llim, mriddle, ndoane |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-10-06 05:14:19 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: | |||
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. > 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. 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. 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? *** This bug has been marked as a duplicate of bug 426672 *** |
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).