-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jason L Tibbitts III wrote:
>>>>> "CW" == Clark Williams
<williams(a)redhat.com> writes:
CW> Just so you know, I have a version of mock that takes a
--rpmlint CW> command line option which will add rpmlint to the
chroot CW> transaction set, install it in the chroot and then run
rpmlint on CW> the generated SRPM and RPMs, putting the output in
an rpmlint.log CW> results file.
Ah, very very cool. One important thing, and the whole reason for
actually doing this, is that in addition to the SRPM and RPMs, you
need to run rpmlint in the chroot on the package name itself. For
example, build the aplus-fsf package under review. rpmlint will
find nothing real to complain about with the SRPM or binary RPMs,
but if you run "rpmlint aplus-fsf" in the chroot with that package
installed you get 3800 warnings.
Well dang, now you're going to make me work for it :).
What I've got now just runs rpmlint inside the chroot on the source
and binary packages. How about we go with that for a bit and let me
think on how we could install into the chroot? I'm not really against
it, since I think it goes with the "chroot manager" task of mock, but
I'd like to look at how to do it without creating more problems than
we solve.
The way I see it, mock's primary mission is to be the tool that
creates a pristine chroot for the purpose of buiding a package (or set
of packages); everything we do here needs to keep that in mind. A
related secondary mission though could be management of a longer lived
chroot used for various purposes (testing, cross-building, etc.).
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)
Comment: Using GnuPG with Fedora -
http://enigmail.mozdev.org
iD8DBQFEumcfHyuj/+TTEp0RAuuLAJ4x0mweM+j+yGwNBJ+mcKb2DA+XeQCeKrcs
mjsmeV5HcgqdONQgUE151+k=
=zNi5
-----END PGP SIGNATURE-----