depcheck - next steps!

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