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.

Advertisements

6 thoughts on “Blarg!

  1. bodhi hackery
    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

    • Re: bodhi hackery
      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:

      A table of all Provides, and
      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.

      • Re: bodhi hackery
        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 🙂

      • Re: bodhi hackery
        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.

      • Re: bodhi hackery
        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

      • Re: bodhi hackery
        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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s