[AutoQA] #328: depcheck: should not test packages from both x86_64 and iX86 unless needed
#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Future tasks Component: tests | Keywords: --------------------+------------------------------------------------------- Right now, depcheck is pulling in all packages (iX86 and x86_64) on x86_64 platforms as pending or accepted. This is not needed and can cause problems with some packages (see #284).
Depcheck should only pull in iX86 packages on x86_64 when those packages are explicitly needed.
#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Future tasks Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kparal):
IIUC the problem is that we place all downloaded packages into a single repo and then depcheck tries to install all those packages. So it could be solved by:
1. instructing depcheck not to install all 32bit packages from the repo, but only those needed as dependencies
or
2. not even placing those unnecessary 32bit packages into that repo
Whether we actually download those packages or not (bandwidth concerns) is not strictly related to this ticket.
#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by kparal):
* milestone: Future tasks => Hot issues
Comment:
Moving to "Hot issues" milestone. As long as we send Bodhi comment, this is an important issue, because we're providing false negative comments to a fair number of packages (possible any package with "conflicts" dependencies across different architectures might be affected).
#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by tflink):
Replying to [comment:1 kparal]:
IIUC the problem is that we place all downloaded packages into a single
repo and then depcheck tries to install all those packages. So it could be solved by:
That's pretty much it. Depcheck tries to install every package that was downloaded, regardless of what architecture it is or if any conflicts exist.
- instructing depcheck not to install all 32bit packages from the repo,
but only those needed as dependencies
I don't think that this would be very difficult. We already have a loop that flags packages for update and we could just add some logic to test for the arch prior to flagging them for update. I don't think that would be more than a couple lines of code.
- not even placing those unnecessary 32bit packages into that repo
This would also work. We could tell koji_utils to just download a specific arch and then not worry about the fact that everything is flagged for update.
Whether we actually download those packages or not (bandwidth concerns)
is not strictly related to this ticket. Agreed, bandwidth usage is a secondary concern. I'm more interested in getting the tests to function correctly ATM.
The other thing I'm not clear on is what we want to do about multilib depcheck runs. How important is it to test multilib stuff in depcheck? If we could figure out a way to be more precise about what packages we're trying to install, I think that would be best in the long run.
I'm thinking something along the lines of extending a fix for #325 to exclude only those iX86 packages that conflict with an x86_64 package but that's not a simple change. Ignoring any packages from a non-matching arch would be a quicker fix.
#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by tflink):
Actually, this looks even easier than I thought it was. If we decide to go ahead with just disabling multilib tests, it's a matter of commenting out three lines in depcheck_lib.py (lines 245-247 on master head).
Not sure if we actually want to do this, though.
#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by jlaska):
A lot of this will probably be stuff you both have already decided on, I'm just coming up to speed on this issue and trying to understand the root cause.
Replying to [comment:4 tflink]:
Actually, this looks even easier than I thought it was. If we decide to
go ahead with just disabling multilib tests, it's a matter of commenting out three lines in depcheck_lib.py (lines 245-247 on master head).
Not sure if we actually want to do this, though.
If we aren't installing i386 *and* x86_64 packages ... do we lose the ability to verify deps for multilib packages? Assuming mash is doing the right thing, and including the expected multilib packages for us ... disabling multi-lib seems like a big loss.
In the wine-wow example sited in the previous ticket, both arch packages are available for install to a x86_64 system. If they are available for install together from the repos, and `yum install` of both packages doesn't complain, the test should be including them both, right? {{{ Available Packages wine-wow.i686 1.3.19-1.fc15 updates- testing wine-wow.x86_64 1.3.19-1.fc15 updates- testing }}}
If I'm reading ticket#284 correctly, it sounds like the spec file intends that the two packages cannot be installed together? {{{ %ifarch x86_64 <snip> Requires: wine-wow(x86-64) = %{version}-%{release} Conflicts: wine-wow(x86-32) = %{version}-%{release} %endif }}}
Which confuses me ... shouldn't ''yum install wine-wow.i686 wine- wow.x86_64'' honor that conflicts and complain, or at least not attempt to install the i686 version? (see full output at http://fpaste.org/1Vc5/)?
{{{ ========================================================================================= Package Arch Version Repository Size ========================================================================================= Installing: wine-wow i686 1.3.19-1.fc15 updates- testing 218 k wine-wow x86_64 1.3.19-1.fc15 updates- testing 221 k Installing for dependencies: cdparanoia-libs i686 10.2-10.fc15 fedora 46 k gd i686 2.0.35-12.fc15 fedora 141 k gstreamer i686 0.10.32-4.fc15 fedora 861 k gstreamer-plugins-base i686 0.10.32-2.fc15 fedora 1.0 M libXpm i686 3.5.8-3.fc15 fedora 58 k libXv i686 1.0.6-2.fc15 fedora 23 k libXxf86vm i686 1.1.1-2.fc15 fedora 21 k libdrm i686 2.4.25-1.fc15 fedora 71 k libexif i686 0.6.20-1.fc15 fedora 317 k libgphoto2 i686 2.4.10.1-1.fc15 fedora 1.0 M libtheora i686 1:1.1.1-1.fc15 fedora 130 k libtool-ltdl i686 2.4-4.fc15 fedora 44 k libusb i686 1:0.1.3-7.fc15 fedora 17 k libusb1 i686 1.0.8-7.fc15 fedora 59 k libvisual i686 0.4.0-10.fc15 fedora 135 k libxml2 i686 2.7.8-6.fc15 fedora 795 k mesa-libGL i686 7.11-0.9.20110509.0.fc15 fedora 145 k mesa-libGLU i686 7.11-0.9.20110509.0.fc15 fedora 176 k nss-mdns i686 0.10-9.fc15 fedora 23 k nss-mdns x86_64 0.10-9.fc15 fedora 22 k orc i686 0.4.14-1.fc15 fedora 147 k wine-common noarch 1.3.19-1.fc15 updates- testing 100 k wine-core i686 1.3.19-1.fc15 updates- testing 13 M wine-core x86_64 1.3.19-1.fc15 updates- testing 13 M
Transaction Summary ========================================================================================= Install 26 Package(s)
Total download size: 32 M Installed size: 204 M Is this ok [y/N]: N Exiting on user Command Complete! }}}
#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by tflink):
Replying to [comment:5 jlaska]:
If I'm reading ticket#284 correctly, it sounds like the spec file
intends that the two packages cannot be installed together?
Yeah, that's how I'm reading it.
Which confuses me ... shouldn't ''yum install wine-wow.i686 wine-
wow.x86_64'' honor that conflicts and complain, or at least not attempt to install the i686 version? (see full output at http://fpaste.org/1Vc5/)?
One would think so, yes. I get the same thing on my F14 x86_64 machine, though.
If I take the example from #324 and attempt 'yum install zabbix-server- mysql zabbix-server-pgsql zabbix-server-sqlite3', yum fails and (correctly) tells me that I can't do that - there are conflicts. So yum is catching conflicts but something about the wine conflict isn't getting caught during dependency resolution.
My guess at this point is that this is a specific issue to packages like wine where the conflicts is within an ifarch block of the spec file.
#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by tflink):
I was digging into this and from what I can tell, yum relies on rpm to tell it what packages have conflicts. With this in mind, I wondered what rpm said about wine-wow.
If I download pacakges for: * [http://kojipkgs.fedoraproject.org/packages/zabbix/1.8.5/1.fc14/x86_64 /zabbix-server-mysql-1.8.5-1.fc14.x86_64.rpm zabbix-server- mysql-1.8.5-1.fc14] * This is a reference since I know yum finds the conflict between this and zabbix-server-sqlite3 * [http://kojipkgs.fedoraproject.org/packages/wine/1.3.19/1.fc14/x86_64 /wine-wow-1.3.19-1.fc14.x86_64.rpm wine-wow-1.3.19-1.fc14]
And run 'rpm --conflicts -qp <rpm file>' (I'm using F14 x86_64) on the packages, I get the following for zabbix-server-mysql: {{{ $ rpm --conflicts -qp zabbix-server-mysql-1.8.5-1.fc14.x86_64.rpm zabbix-server-pgsql zabbix-server-sqlite3 }}}
But when I do the same to wine-wow: {{{ $ rpm --conflicts -qp wine-wow-1.3.19-1.fc14.x86_64.rpm }}}
I get nothing. I would have expected a conflicts on wine-wow
It turns out that the Conflicts is within wine, not wine-wow. So wine.x86_64 conflicts with wine-wow.i686 but there are no issues between the different arches of wine-wow. Running 'yum install wine wine.i686' confirms this.
The only way I can think of for us to work around this is to check for conflicts on all packages and their parents in order to keep from installing conflicting packages. I wonder what would happen if the installation of wine-wow.x86_64 and wine-wow.i386 was allowed to continue since that's pulling in both arches of wine-core.
#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kparal):
Replying to [comment:7 tflink]:
It turns out that the Conflicts is within wine, not wine-wow. So
wine.x86_64 conflicts with wine-wow.i686 but there are no issues between the different arches of wine-wow. Running 'yum install wine wine.i686' confirms this.
That's correct, easy to check here: * http://koji.fedoraproject.org/koji/rpminfo?rpmID=2535516 * http://koji.fedoraproject.org/koji/rpminfo?rpmID=2535517
#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Depcheck Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by kparal):
* milestone: Hot issues => Depcheck
autoqa-devel@lists.fedorahosted.org
-
fedora-badges