#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.
> 1. 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.
> 2. 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.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/328#comment:3>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
_______________________________________________
autoqa-devel mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/autoqa-devel
