Some SourcePackageRecipeBuild attributes seem redundant

Bug #513201 reported by Michael Nelson
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
Medium
Paul Hummer

Bug Description

I've just added a dia diagram of the current source package recipe tables in db-devel:

https://dev.launchpad.net/BuildBranchToArchive#Current%20db-devel%20schema

and can't see why we've got sourcepackagename and distroseries on SourcePackageRecipeBuild when they're already on the related SourcePackageRecipe (and I assume won't change?).

Related branches

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Well, you've hit the nail on the head -- can you be sure the details on the SourcePackageRecipe won't change? The only reason the analogous fields for branches can't be changed is a lack of UI (you might even be able to change them through the API already).

Revision history for this message
Jonathan Lange (jml) wrote :

What would changing mean here? That the recipe to build a package now has a new purpose and is there to build a different package, or the same package in a different series. Is that actually something we should allow? I don't really know

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Well, what does it mean for branches? It's a bit of a vague concept. I agree. I'm not sure if we should allow it -- I should have emphasized in my first comment that I was being very paranoid on this point when I wrote the db patch.

I think the most likely situation where we might want to allow this is when the details of how the source packages are arranged changes. like a library being refactored out of an application or something. But I certainly haven't thought about it that hard.

Revision history for this message
Michael Nelson (michael.nelson) wrote :

As mentioned on bug 516448, building the same package in different series is probably something very desirable. That bug is about updating the schema and builder to support building the source package once, and then potentially re-building the binaries for different distroseries (ie. something that we've not done before).

But as a fall-back measure, the less efficient creation of 4 separate builds for the one recipe (mentioned by jml above) might be one good reason for having distroseries on the SPRBuild, as it seems we might want to allow it.

Revision history for this message
Michael Nelson (michael.nelson) wrote :

Regarding the 4 separate builds for one recipe, see Comment 3 on https://bugs.edge.launchpad.net/launchpad-code/+bug/516496 (and hopefully any clarification following).

Revision history for this message
Tim Penhey (thumper) wrote :

I guess we'll re-evaluate this once we have bedded down the design a bit more.

Changed in launchpad-code:
status: New → Triaged
importance: Undecided → Medium
tags: added: recipe
Revision history for this message
Aaron Bentley (abentley) wrote :

Distroseries now has a a many-to-many relationship with SourcePackageRecipes, but a given build is for a single distroseries, so this field is required. Not sure whether sourcepackagename is actually redundant.

Revision history for this message
Aaron Bentley (abentley) wrote :

I think SourcePackageRecipeBuild.sourcepackagename is redundant with SourcePackageRelease.sourcepackagename. SourcePackageRecipe.sourcepackagename should either be removed or be treated as a cache of the last-built sourcepackagerelease's sourcepackagename.

Revision history for this message
Ursula Junque (ursinha) wrote : Bug fixed by a commit
Changed in launchpad-code:
assignee: nobody → Paul Hummer (rockstar)
milestone: none → 10.05
status: Triaged → Fix Committed
tags: added: qa-needstesting
Curtis Hovey (sinzui)
Changed in launchpad-code:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.