Will Woods, Fedora Testing Guy ([info]qa_rockstar) wrote,
@ 2007-06-19 17:39:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Blarg!
Yeah, I'm bad at updating my interblag. Sorry about that.

So I've been trying to put together a small tool that does depchecking (so we can stop having updates go out with missing deps, like the recent F7 kernel update) and finding a clever way to integrate this with bodhi.

Ideally we'll choose a well-defined test reporting data format (there's a bunch out there) and write a test result aggregator thingy for Beaker. Then we'll give bodhi a little widget that shows per-package results from Beaker.

Unfortunately I got distracted for most of the day chasing down a problem with crond and selinux-policy-targeted-2.6.4-17.fc7. I think I got all the right info to the right people, so that should get worked out before we release new selinux-policy packages.

Anyway, for the depchecker I need to figure out how to properly enumerate a package's Provides: entries. A package can have explicit Provides, but it also provides each file in its file lists, and its package name, and its package NVR.. and maybe there's other stuff too?

I've gotta go read some more yum code and figure this out.

(Post a new comment)

darn it!
[info]skvidal
2007-06-20 04:53 am UTC (link)
I was in rdu for the last 2 days for orientation. I wished I had run into you. it would have been good to sit down and figure out what it is you need so we can make it all work.

drop me an email or find me on irc and we'll talk some more.

(Reply to this)

bodhi hackery
[info]notweak
2007-06-20 05:28 am UTC (link)
I started thinking about how we could write a depchecker for bodhi, and I don't think it'll be too hard.

So when we add an update, we can easily grab the provides from koji:
    build = koji.getBuild(nvr)
    for rpm in koji.listBuildRPMs(build['id']):
        deps = koji.listRPMDeps(rpm['id'])

From here we can throw all of the Provides in a table in bodhi, I think something as simple as this would probably suffice (there are a couple of other fields from listRPMDeps() that we may want to store as well (flags, versions, etc)):
    class Capabilities(SQLObject):
        name    = UnicodeCol()
        package = ForeignKey('Package')
        release = ForeignKey('Release')

Then before adding an update we just make sure we have all of the proper capabilities for the specified Release

I revamped a lot of bodhi's model (giving it support for multi-build updates, QA approved & timestamp, feedback rating, etc) in the past week, so if we're going to add any new tables, now is the time.


luke

(Reply to this) (Thread)
Re: bodhi hackery
[info]qa_rockstar
2007-06-20 03:24 pm UTC (link)
Dep flags are definitely required - you need to know the difference when a package requires foo < X.Y.Z versus foo > X.Y.Z.

I'm a bit confused about how keeping a table of Provides helps.

Let's define the problem. So, in theory we have a big directed graph of packages, arrows representing a requirement on something another package requires. When we want to update a set of packages U, we need to find all packages (X,Y,Z,...) where each package Requires something in U.

repoclosure iterates over all the Requires arrows for all packages and makes sure they all point to a valid package. Effective, but slow.

As I understand it, the method you're suggesting requires two things:
  1. A table of all Provides, and
  2. A table of all Requires
So for each update, you check to see that the new package(s) have a Provide for each Require listed. We're pulling the info out of the database now, but this still requires iterating over the entire list of Requires, doesn't it?

I'd like to keep a RequiredBy table - a simple mapping of Name -> Name will suffice - so we can avoid checking every Requires for all 8600+ packages every time. Every time we send out an update, we need to update the RequiredBy table, but that's the same as keeping a table of Requires or Provides.

(Reply to this) (Parent)(Thread)
Re: bodhi hackery
[info]notweak
2007-06-20 03:45 pm UTC (link)
No, the method I posed above only keeps a table of Provides. So when we add a new update we simply iterate over the new updates Requires, and check that each one exists. We could potentially do it in a single db query :)

(Reply to this) (Parent)(Thread)
Re: bodhi hackery
[info]qa_rockstar
2007-06-20 03:51 pm UTC (link)
But what about all the packages that depend on the updated package? You've accounted for the outgoing arrows but you're missing the incoming ones. That's the hard bit, since those arrows come from outside the package - they're not listed in the package metadata at all.

That's why I want to keep a table of all the Requires, or the imaginary RequiredBy field.

(Reply to this) (Parent)(Thread)
Re: bodhi hackery
[info]notweak
2007-06-20 05:29 pm UTC (link)
Maybe I'm missing something here, but I don't see how my proposed method wouldn't work for that?

- dev clicks 'Add update(s)'
- bodhi checks the update(s) Requires against all Provides in bodhi's db (for that release), as well as all of the Provides in the proposed update(s).
- If things match up, add the update(s) Provides to bodhi, and save the update

(Reply to this) (Parent)(Thread)
Re: bodhi hackery
[info]qa_rockstar
2007-06-20 08:33 pm UTC (link)
I think you're forgetting the incoming Requires arrows. You're only checking the updated packages requirements - i.e. outgoing Requires arrows. What about other packages that require things from the updated packages? What about when the updated packages change their Provides?

As an example: you're updating kitten-blender, and my package kpetmulcher requires libkittenblender.so.1. But your new kitten-blender-libs package provides libkittenblender.so.2. Your update's Requires are all satisfied, but (I think) yum will refuse to install that update because it would break kpetmulcher's deps.

Even if it doesn't break the update transaction, it breaks kpetmulcher. So we need to detect this condition and send mail to the kpetmulcher maintainer and/or attempt a kpetmulcher rebuild.

(Reply to this) (Parent)
Interesting joke!
(Anonymous)
2007-10-14 12:14 pm UTC (link)
Three young boys were fighting over whose dad was the best.
"My dad is so good he can shoot an arrow, run after it, get in front of it, and catch it in his bare hands."
"My dad is so good that he can shoot a gun, run after the bullet, get in front of it and catch it in his bare hands."
"I've got you both beat. My dad's so good because he works for the city. He gets off work at 5:00 and is home by 4:30."


The latest news of the world of the finance interests look Signature.

(Reply to this)

Проститутки Днепропетровска досуг intim sex мадам
(Anonymous)
2008-02-03 10:30 am UTC (link)
Проститутки Донецка досуг intim sex Девочки
сайт http://kurtizanka.com.ua
kurtizanka.com.ua

(Reply to this)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…