bucketmetadata has a key for source package but daisy inserts binary package

Bug #1159996 reported by Brian Murray on 2013-03-25
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Looking at update_bucket_metadata we can see the following:

def update_bucket_metadata(config, bucketid, source, version, comparator, release=''):
   if metadata:
        metadata['Source'] = source

So it appears that bucketmetadata is intended to contain information about source packages, however looking at the data we find 'compiz-core', 'jockey-gtk', 'chromium-browser', and many other binary packages.

Looking into utils.py from daisy we see the following:

def bucket(oops_config, oops_id, crash_signature, report_dict):
    package = report_dict.get('Package', '')

In apport reports 'Package' is the binary package and 'SourcePackage' is the SourcePackage. For the work I'm doing now, phased updates, I'd like the source package to be in bucketmetadata and it appears that was the intent. However, we should check to see if there are other cases where bucketmetadata is queried for the binary package and not the source package.

Changed in daisy:
importance: Undecided → High
Brian Murray (brian-murray) wrote :

most_common_problems in errors/api/resources.py says that it is getting Source but it is really getting binary since that is what was inserted and in this case we do want binaries.

bucket in errors/view.py could use either binary or source package as it is just displaying the name and then links a Launchpad page for that package, which contains information about published versions of that package (which would be the same for the binary or source package).

Brian Murray (brian-murray) wrote :

I thought that bucket systems should actually link to the source package page in Launchpad, since its information is not release specific, and made that change in bug 1160023.

Subsequently, I think the right thing to do is to rename Source in the metadata bucket to Binary and modify the code accordingly. However, I've no idea how to rename that in cassandra.

Evan (ev) wrote :

[15:48:56] <ev> the short answer is more poor naming on my part
[15:49:19] <ev> because I was in the "this part of the code base will be shared with the regular python-oops stuff" I called it Source as in the source it came from
[15:49:25] <ev> being a binary package or something else
[15:49:27] <ev> which was silly
[15:49:31] <ev> you're right
[15:49:36] <ev> it should be called "binary"
[15:50:44] <ev> it's not an easy thing to fix. We'll have to change it in the code to write to "binary", write the existing "source" columns to "binary", then delete "source" row by row
[15:51:43] <bdmurray> that sounds arduous
[15:52:09] <ev> yeah :-/

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers