Forwarding wwoods' replies here.
----- Forwarded Message -----
From: "Will Woods" <wwoods(a)redhat.com>
To: "Kamil Paral" <kparal(a)redhat.com>
Sent: Friday, February 11, 2011 8:37:02 PM
Subject: Re: depcheck test, version 2
On Fri, 2011-02-11 at 14:26 -0500, Kamil Paral wrote:
----- Original Message -----
> Ha, yeah, I forgot to wire up --selftest. You can run the selftests
> just
> by doing ./depcheck_unittest.py.
One question to wwoods:
depcheck_unittest.py requires to be run on amd64 because of those
multilib test cases, right? I haven't managed to get it running on
i386.
If it is the case, I'll add a short architecture detection to the
beginning of the test and print out warning if it is executed on a
wrong arch.
...ick. Yes, the tests that exist are currently correct for x86_64 only.
They used to also work on i386 but not anymore, I guess. We should
probably have different versions of the multilib tests that expect
different results, depending on whether you're on a multiarch or
singlearch system.
One question to sheer public:
(I'm not sure what you mean by "sheer public" here? But anyway..)
I have found out that depcheck_unittest.py requires a few packages I
didn't have installed, specifically python-rpmfluff, rpm-build and
mash. How are we gonna track these dependencies? We use autoqa.spec
for managing runtime dependencies of autoqa and we use setup() methods
for managing dependencies of individual tests. But what about
dependencies of our unittests?
Should we add those to the autoqa.spec? Should we add "make test-deps"
command to install those deps?
Probably the latter one - the unittests are only interesting to people
who are probably going to be modifying the test and testing its changes,
so we don't want to pull those in for everyone.
It might make sense to add a BuildRequires: line for them, though?
> Yeah, this is unnecessary but not technically wrong. Mostly I wanted
to
> avoid encoding any multilib policy/logic into the test wrapper, but
if
> you want to do:
>
> if arch == 'i686':
> download_pkgs(arch)
> else:
> download_pkgs(both_arches)
>
> that's fine.
We will probably need to hold on this because of
https://fedorahosted.org/autoqa/ticket/272
I don't know how to detect OS arch and HW arch may not match.
Right. And hopefully, downloading packages should be a fairly quick
operation when we're running this in production; it's not a huge loss if
it takes 20 seconds instead of 10 seconds on i686. We can fix that
later.
-w