depcheck - next steps!

[Will Woods]

Time for a Depcheck Roundup! Whee!

So now that I've messed with the unittests a bit and proven to myself
that yes, depcheck does what it's supposed to (at least for *trivial*
cases) it's time to look at the next steps:

== write control/control.autoqa/test wrapper object ==

I took a stab at this in the depcheck branch but I'm pretty sure I did
it wrong / left some stuff out. Kamil/Joza, if you guys can give me some
help/pointers here I'd appreciate it... but don't worry, I'll send the
patch to the list for a final review before I merge anything.

== integrate mash ==

Basically, we need to be using the 'mash' tool rather than 'createrepo'
to create the repos we use when testing updates, otherwise we'll miss
anything involving multilib (like the infamous nss-softokn bug). I'm not
at all sure how mash works - does anyone want to volunteer to figure
this out?

== more test cases ==

Once we're using mash instead of createrepo, we'll want to a) write a
unittest or two to be sure mash is doing what it's supposed to, and b)
write some depcheck unittests that prove depcheck handles multilib
problems (and normal multilib packages) properly.

== Get it running in autoqa! ==

Technically, we could start running depcheck *before* we finish the mash
work - we just would ignore all multilib issues. I feel like we should
wait until depcheck is working *correctly* before wiring it up, but
maybe it would be helpful to have it partially working? What do you all
think?

== And beyond.. ==

Once we're satisfied that depcheck is working and doing the right
thing.. then we actually talk to rel-eng and infrastructure about wiring
up the proper bits so we can *reject* packages that fail depcheck.
Exciting stuff! Expect flamewars!

Just to state the obvious: we're probably not going to have depcheck
working by F14Alpha. Oh well. But I am undaunted - we're getting reeally
close.

Anything else depcheck-related that I'm forgetting about here? I need to
review the trac tickets, I think..

-w