Bug 1080533
| Summary: | rrdtool has multilib conflicts | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Alois Mahdal <amahdal> | ||||
| Component: | rrdtool | Assignee: | Jaroslav Škarvada <jskarvad> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-daemons | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.6 | CC: | amahdal | ||||
| Target Milestone: | rc | Keywords: | Regression | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-03-28 16:22:10 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Note that this was scheduled manually using bkr worlflow-tomorrow --errata 2014:17107 --tps-rpmtest --reserve --variant=all Strange that equivalent TPS---launched yesterday on "stable" machine---passed. (In reply to Alois Mahdal from comment #0) > file /usr/bin/rrdcgi from install of rrdtool-1.3.8-7.el6.i686 conflicts > with file from package rrdtool-1.3.8-6.el6.i686 This doesn't seem like multilib conflict and it doesn't seem like problem with the 1.3.8-6 as stated in the comment 0. Please note, the latest version is 1.3.8-7. I am unable to reproduce the problem: # yum install ./rrdtool-devel-1.3.8-7.el6.i686.rpm ./rrdtool-devel-1.3.8-7.el6.x86_64.rpm ./rrdtool-doc-1.3.8-7.el6.i686.rpm ./rrdtool-doc-1.3.8-7.el6.x86_64.rpm ./rrdtool-perl-1.3.8-7.el6.i686.rpm ./rrdtool-perl-1.3.8-7.el6.x86_64.rpm ./rrdtool-php-1.3.8-7.el6.i686.rpm ./rrdtool-php-1.3.8-7.el6.x86_64.rpm ./rrdtool-ruby-1.3.8-7.el6.i686.rpm ./rrdtool-ruby-1.3.8-7.el6.x86_64.rpm ./rrdtool-tcl-1.3.8-7.el6.i686.rpm ./rrdtool-tcl-1.3.8-7.el6.x86_64.rpm ./rrdtool-1.3.8-7.el6.i686.rpm ./rrdtool-1.3.8-7.el6.x86_64.rpm ... Installed: rrdtool.i686 0:1.3.8-7.el6 rrdtool.x86_64 0:1.3.8-7.el6 rrdtool-devel.i686 0:1.3.8-7.el6 rrdtool-devel.x86_64 0:1.3.8-7.el6 rrdtool-doc.i686 0:1.3.8-7.el6 rrdtool-doc.x86_64 0:1.3.8-7.el6 rrdtool-perl.i686 0:1.3.8-7.el6 rrdtool-perl.x86_64 0:1.3.8-7.el6 rrdtool-php.i686 0:1.3.8-7.el6 rrdtool-php.x86_64 0:1.3.8-7.el6 rrdtool-ruby.i686 0:1.3.8-7.el6 rrdtool-ruby.x86_64 0:1.3.8-7.el6 rrdtool-tcl.i686 0:1.3.8-7.el6 rrdtool-tcl.x86_64 0:1.3.8-7.el6 On the test system the rrdtool-python couldn't be installed multilib, because there is no 32 bit python interpreter in the 64 bit computenode repo (please note this is not packaging problem). Also debuginfo packages for binaries (not libs) cannot be installed both 32 bit and 64 bit at the same time (you can install only one variant at a time). AFAIK this is a limitation / bug of the RPM not coloring the /usr/lib/debug/usr/bin/* files. I think this is not big issue, because multilib is for libs. I think you can open bug against RPM (if there is none). So the only problem I can see now are missing ARCH deps in subpackages. This is very minor problem and probably not worth fixing in RHEL-6. (In reply to Jaroslav Škarvada from comment #4) > > This doesn't seem like multilib conflict and it doesn't seem like problem > with the 1.3.8-6 as stated in the comment 0. Please note, the latest version > is 1.3.8-7. Sorry, I mis-typed the versions, it should read "-7". ~ > I am unable to reproduce the problem: And as I mentioned, on "stable" systems scheduled based on errata tool, the same test passed. Then I scheduled it in Beaker (for other reason) and it failed. Then you tried it and it passed. Then, today, after reading your comment I tried to schedule the same about 4 more times and one of them failed. From my POV, now it's either 2 false positives or 5 false negatives. (Or phase-of-the-moon bug. Or exact-angle-between-clock-hands-modulo-13 bug. Or some-TPS-randomness.) ~ > On the test system the rrdtool-python couldn't be installed multilib, > because there is no 32 bit python interpreter in the 64 bit computenode repo > (please note this is not packaging problem). (Is this what RPM/TPS tried to say to me..? ;) OK, not a packaging problem ... and IIUC nothing new for 1.3.8-7. ~ > Also debuginfo packages for binaries (not libs) cannot be installed both 32 > bit and 64 bit at the same time (you can install only one variant at a > time). AFAIK this is a limitation / bug of the RPM not coloring the > /usr/lib/debug/usr/bin/* > files. OK, I heard about this. We can forget about the debuginfo lines (for now). ~ > I think this is not big issue, because multilib is for libs. I;ve beeb told that the policy is that multilib is for libs only (unless there is a *really* good reason for exception), but I'm not sure how it applies to rrdtool, especially because of this: file /usr/bin/rrtdool from install of rrdtool-1.3.8-7... file /usr/lib/librrd.so.4.0.7 from install of rrdtool-1.3.8-7... So it has both: CLI tools and and a library. Now is rrdtool-1.3.8-7.el6 a "lib" or not? (AFAIK .rrd files produced by the CLI tools are arch-specific binary blobs, although that does not seem like really good reason, if even explanation.) ~ Now have I fulfilled the "needinfo" request? (In reply to Alois Mahdal from comment #5) > > I am unable to reproduce the problem: > > And as I mentioned, on "stable" systems scheduled based on errata tool, the > same test passed. Then I scheduled it in Beaker (for other reason) and it > failed. Then you tried it and it passed. Then, today, after reading your > comment I tried to schedule the same about 4 more times and one of them > failed. > > From my POV, now it's either 2 false positives or 5 false negatives. > > (Or phase-of-the-moon bug. Or exact-angle-between-clock-hands-modulo-13 > bug. Or some-TPS-randomness.) > No such exists :) I don't know internals of TPS, but by looking into logs you provided me I noticed the following snip: old packages that are missing: old : missing : rrdtool-doc-1.3.8-6.el6.x86_64 old : missing : rrdtool-ruby-1.3.8-6.el6.x86_64 old : missing : rrdtool-tcl-1.3.8-6.el6.x86_64 old : missing : rrdtool-perl-1.3.8-6.el6.x86_64 old : missing : rrdtool-1.3.8-6.el6.x86_64 old : missing : rrdtool-python-1.3.8-6.el6.x86_64 old : missing : rrdtool-php-1.3.8-6.el6.x86_64 old : missing : rrdtool-devel-1.3.8-6.el6.x86_64 old : missing : rrdtool-debuginfo-1.3.8-6.el6.x86_64 doRpmCommand: rpm -U /mnt/redhat/brewroot/packages/rrdtool/1.3.8/7.el6/x86_64/rrdtool-1.3.8-7.el6.x86_64.rpm /mnt/redhat/brewroot/packages/rrdtool/1.3.8/7.el6/x86_64/rrdtool-tcl-1.3.8-7.el6.x86_64.rpm /mnt/redhat/brewroot/packages/rrdtool/1.3.8/7.el6/i686/rrdtool-devel-1.3.8-7.el6.i686.rpm /mnt/redhat/brewroot/packages/rrdtool/1.3.8/7.el6/i686/rrdtool-1.3.8-7.el6.i686.rpm /mnt/redhat/brewroot/packages/rrdtool/1.3.8/7.el6/x86_64/rrdtool-doc-1.3.8-7.el6.x86_64.rpm /mnt/redhat/brewroot/packages/rrdtool/1.3.8/7.el6/x86_64/rrdtool-python-1.3.8-7.el6.x86_64.rpm /mnt/redhat/brewroot/packages/rrdtool/1.3.8/7.el6/x86_64/rrdtool-php-1.3.8-7.el6.x86_64.rpm /mnt/redhat/brewroot/packages/rrdtool/1.3.8/7.el6/x86_64/rrdtool-perl-1.3.8-7.el6.x86_64.rpm /mnt/redhat/brewroot/packages/rrdtool/1.3.8/7.el6/x86_64/rrdtool-debuginfo-1.3.8-7.el6.x86_64.rpm /mnt/redhat/brewroot/packages/rrdtool/1.3.8/7.el6/x86_64/rrdtool-devel-1.3.8-7.el6.x86_64.rpm /mnt/redhat/brewroot/packages/rrdtool/1.3.8/7.el6/x86_64/rrdtool-ruby-1.3.8-7.el6.x86_64.rpm doRpmCommand-result (2816): error: Failed dependencies: rrdtool = 1.3.8-6.el6 is needed by (installed) rrdtool-php-1.3.8-6.el6.i686 rrdtool = 1.3.8-6.el6 is needed by (installed) rrdtool-ruby-1.3.8-6.el6.i686 rrdtool = 1.3.8-6.el6 is needed by (installed) rrdtool-tcl-1.3.8-6.el6.i686 rrdtool = 1.3.8-6.el6 is needed by (installed) rrdtool-perl-1.3.8-6.el6.i686 rrdtool = 1.3.8-6.el6 is needed by (installed) rrdtool-python-1.3.8-6.el6.i686 So, e.g. there is installed rrdtool-1.3.8-6.el6.i686 and rrdtool-php-1.3.8-6.el6.i686 and you are upgrading to / installing rrdtool-1.3.8-7.el6.x86_64.rpm, rrdtool-1.3.8-7.el6.i686.rpm, rrdtool-php-1.3.8-7.el6.x86_64.rpm, but *no* rrdtool-php-1.3.8-7.el6.i686. The same for ruby, tcl, python subpackages. That's why the deps cannot be fulfilled and the transaction failed. > > On the test system the rrdtool-python couldn't be installed multilib, > > because there is no 32 bit python interpreter in the 64 bit computenode repo > > (please note this is not packaging problem). > > (Is this what RPM/TPS tried to say to me..? ;) > > OK, not a packaging problem ... and IIUC nothing new for 1.3.8-7. > No idea why it worked in TPS, maybe it used different repo. IIRC I used latest nightly computenode compose. > > I think this is not big issue, because multilib is for libs. > > I;ve beeb told that the policy is that multilib is for libs only (unless > there is a *really* good reason for exception), but I'm not sure how it > applies to rrdtool, especially because of this: > > file /usr/bin/rrtdool from install of rrdtool-1.3.8-7... > file /usr/lib/librrd.so.4.0.7 from install of rrdtool-1.3.8-7... > > So it has both: CLI tools and and a library. Now is rrdtool-1.3.8-7.el6 a > "lib" or not? > I can split the package, but I am not sure whether it is worth doing (especially on RHEL-6 and as a workaround for RPM / TPS bugs). The libs itself occupy cca. 530 kB, the package including bins and docs occupies about 900 kB, this means less then 370 kB (calculations taken on f20) to save by the split in cases when the tools are not needed (I think not too much cases as rrdupdate is often called from the collecting scripts). Could you just instruct TPS not to install rrdtool-debuginfos in parallel? (In reply to Jaroslav Škarvada from comment #7) > > So, e.g. there is installed rrdtool-1.3.8-6.el6.i686 and > rrdtool-php-1.3.8-6.el6.i686 and you are upgrading to / installing > rrdtool-1.3.8-7.el6.x86_64.rpm, rrdtool-1.3.8-7.el6.i686.rpm, > rrdtool-php-1.3.8-7.el6.x86_64.rpm, but *no* rrdtool-php-1.3.8-7.el6.i686. > The same for ruby, tcl, python subpackages. That's why the deps cannot be > fulfilled and the transaction failed. > > [...] > > No idea why it worked in TPS, maybe it used different repo. IIRC I used > latest nightly computenode compose. I've verified on RHN that these rrdtool-[a-z]*.i686 have never been released, so they shouldn't have been there in the first place. So probably harness or TPS or something else failed in preparing the environment. Removing these packages and running the test again results in PASS. ~ > I can split the package, but I am not sure whether it is worth doing > (especially on RHEL-6 and as a workaround for RPM / TPS bugs). No, it's probably not worth (the risk?) for RHEL6. However, it's strange that two packages that both contain their versions of /usr/bin/rrdtool can "co-exist". And indeed: # rpm -q rrdtool rrdtool-1.3.8-7.el6.x86_64 rrdtool-1.3.8-7.el6.i686 # file `which rrdtool` /usr/bin/rrdtool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped # rpm --no-deps -e rrdtool.x86_64 # rpm -q rrdtool rrdtool-1.3.8-7.el6.i686 # rpm -ql rrdtool | head -3 /usr/bin/rrdcgi /usr/bin/rrdtool /usr/bin/rrdupdate # rrdtool -bash: rrdtool: command not found # rpm -V rrdtool # # echo Now that\'s some black.spec magic! Now that's some black.spec magic! So, to protect future generations though, I'm going to file this for RHEL7. ~ > Could you just instruct TPS not to install rrdtool-debuginfos in parallel? Turns out that conflicts in debuginfo alone would not trigger the TPS fail; it has some logic reflecting the fact that it's a known bug/limitation in RPM and ignoring the failures. ~ So provided that the rest is OK, we can simply close this bug. Thank you and azelinka for help in resolving this. (In reply to Alois Mahdal from comment #8) Thanks for the info, I am going to close this. > However, it's strange that two packages that both contain their versions of > /usr/bin/rrdtool can "co-exist". And indeed: > > # rpm -q rrdtool > rrdtool-1.3.8-7.el6.x86_64 > rrdtool-1.3.8-7.el6.i686 > # file `which rrdtool` > /usr/bin/rrdtool: ELF 64-bit LSB executable, x86-64, > version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux > 2.6.18, > stripped > # rpm --no-deps -e rrdtool.x86_64 > # rpm -q rrdtool > rrdtool-1.3.8-7.el6.i686 > # rpm -ql rrdtool | head -3 > /usr/bin/rrdcgi > /usr/bin/rrdtool > /usr/bin/rrdupdate > # rrdtool > -bash: rrdtool: command not found > # rpm -V rrdtool > # > # echo Now that\'s some black.spec magic! > Now that's some black.spec magic! > This is OK, that's how rpm supports multilib. It uses coloring for this, so if two files with the same name/path differ and are in some hardcoded paths used for binaries (e.g. /usr/bin) the version from the native arch wins and is installed (i.e. x86_64 in this case). The conflict only occurs if the files are outside of this magic paths and are different. This makes perfect sense, because mostly there is no need to run 32 bit binaries from distro packages on 64 bit arch. If there is such obscure need, it can be workaround by special suffix, directory path or similar. > So, to protect future generations though, I'm going to file this for RHEL7. > I can't see any benefit in splitting the package, so I would let it as is. The only thing that could be fixed in rawhide (or maybe RHEL-7) is adding arch deps, i.e. the 32 bit devel subpackage requiring exactly the 32 bit base package, because now the dep for the 32 bit devel subpackage (and others) is satisfied simply by the 64 bit base package, which is apparently not correct. But this is very minor issue and most of the users would be never hit by this. |
Created attachment 878550 [details] tps-rpmtest.log Description of problem: tps-rpmtest fails on ComputeNode x86_64 due to multilib conflicts. See attached log and excerpt below. Version-Release number of selected component (if applicable): rrdtool-1.3.8-6.el6.i686 rrdtool-1.3.8-6.el6.x86_64 Output from RPM Command: file /usr/lib/debug/usr/bin/rrdcgi.debug from install of rrdtool-debuginfo-1.3.8-7.el6.x86_64 conflicts with file from package rrdtool-debuginfo-1.3.8-6.el6.i686 file /usr/lib/debug/usr/bin/rrdtool.debug from install of rrdtool-debuginfo-1.3.8-7.el6.x86_64 conflicts with file from package rrdtool-debuginfo-1.3.8-6.el6.i686 file /usr/lib/debug/usr/bin/rrdupdate.debug from install of rrdtool-debuginfo-1.3.8-7.el6.x86_64 conflicts with file from package rrdtool-debuginfo-1.3.8-6.el6.i686 file /usr/src/debug/rrdtool-1.3.8/bindings/perl-shared/RRDs.c from install of rrdtool-debuginfo-1.3.8-7.el6.x86_64 conflicts with file from package rrdtool-debuginfo-1.3.8-6.el6.i686 file /usr/src/debug/rrdtool-1.3.8/src/rrd_graph.c from install of rrdtool-debuginfo-1.3.8-7.el6.x86_64 conflicts with file from package rrdtool-debuginfo-1.3.8-6.el6.i686 file /usr/bin/rrdcgi from install of rrdtool-1.3.8-7.el6.i686 conflicts with file from package rrdtool-1.3.8-6.el6.i686 file /usr/bin/rrdtool from install of rrdtool-1.3.8-7.el6.i686 conflicts with file from package rrdtool-1.3.8-6.el6.i686 file /usr/bin/rrdupdate from install of rrdtool-1.3.8-7.el6.i686 conflicts with file from package rrdtool-1.3.8-6.el6.i686 file /usr/lib/librrd.so.4.0.7 from install of rrdtool-1.3.8-7.el6.i686 conflicts with file from package rrdtool-1.3.8-6.el6.i686 file /usr/lib/librrd_th.so.4.0.7 from install of rrdtool-1.3.8-7.el6.i686 conflicts with file from package rrdtool-1.3.8-6.el6.i686 file /usr/lib/tclrrd1.3.8.so from install of rrdtool-devel-1.3.8-7.el6.i686 conflicts with file from package rrdtool-tcl-1.3.8-6.el6.i686 file /usr/lib/tclrrd1.3.8.so from install of rrdtool-devel-1.3.8-7.el6.i686 conflicts with file from package rrdtool-devel-1.3.8-6.el6.i686 file /usr/share/man/man3/RRDp.3pm.gz from install of rrdtool-perl-1.3.8-7.el6.x86_64 conflicts with file from package rrdtool-perl-1.3.8-6.el6.i686 file /usr/share/man/man3/RRDs.3pm.gz from install of rrdtool-perl-1.3.8-7.el6.x86_64 conflicts with file from package rrdtool-perl-1.3.8-6.el6.i686