launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Friday 18 September 2009 12:39:52 William Grant wrote:
> On Fri, 2009-09-18 at 10:05 +0100, Julian Edwards wrote:
> > This is probably a good assumption, it will make things easier, although
> > I worry that it is easily broken.
> 
> AFAICT there is no other way to determine the corresponding deb.
> Assuming that we restrict the search to the ddeb's build, how could it
> break? Remember that ddebs are automatically generated, so they should
> either match or there is an Ubuntu Developer playing tricks, in which
> case we have bigger problems.

The main problem is that it's very hard to do database queries when you rely 
on funky name formatting.

The ddeb is uploaded with the .ddeb filename extension, then the 
IBinaryPackageRelease.binpackageformat is be DDEB.  To match these to the 
regular DEB we could introduce a link table, which is populated by process-
upload, assuming that the ddeb is in the same upload as the deb (which it 
should always be).  At that stage we probably have no choice but to use a 
naming format to associate them.

> > I think that ddebs should not skip NEW and should do whatever the
> > corresponding deb does, including overrides.
> 
> As we discussed on IRC, they really should skip NEW. That is, the binary
> upload will only be held in NEW if the debs are NEW -- a ddeb is
> insufficient to hold it.

Yes - this is what I meant but English is only my first language so I messed 
that up horribly :)

> This doesn't quite match the current implementation, which I know to be
> buggy anyway. This can be fixed by just always having a ddeb inherit its
> corresponding deb's overrides. If the deb is NEW, no overrides for the
> ddeb will be found, so both will end up NEW. If the deb is not NEW, the
> ddeb will inherit the deb's overrides, and so will not be new. This also
> fixes bug #430025 (Primary archive ddebs always end up in universe).
> Some trickery will be required to avoid forcing archive admins to
> initially override both deb and ddeb seperately.

I think we can always present the deb and ddeb as a single item in the UI.  
This way, you have no choice but to accept/deny/override them together.

We'll need to fix the +queue page, the queue tool script and change-
override.py to do that.

We could also just never present the ddeb in the UI and make it Just Work in 
the background.  Would the archive admins want to know if one was present or 
not?

> Most of it is already fairly well encapsulated, but perhaps the whole
> source/binary/children selection mechanism that several scripts use
> should be factored out.

Automatic +1 from me to any refactoring.

> I considered that, but I don't particularly like the idea of including
> partner in the calculation. Its set of packages and builds should be
> disjoint from the rest, but it still feels a bit icky. I'm somewhat
> considering a new Archive attribute which contains a list of grouped
> archives. But perhaps that's over-complicating things, given that it
> would be used for just this single case at present.

Yes, it's much easier to just live with partner in the list.  I think the 
complaints I heard so far about that can all be solved with UI presentation 
changes; there's no need to change our model or code.

> Right, intra-archive delayed copies are pretty broken at the moment
> (although only because they perform a now-insane sanity check that there
> are no existing ACCEPTED or DONE uploads in the archive for that
> version?), but I don't think there's anything special that needs to be
> done make the ddeb bits work.

It should be fine, yep.

> I verified yesterday that PPA->primary delayed copies handle the debug
> archive correctly.

Fantastic.

> It seems pretty bad to have the method override the given archive, but I
> see it started doing that to the component earlier this week. I guess it
> makes sense.

Yes, it's a publishing detail and therefore should live in the publishing 
class.

> > > While direct copies *into* a primary archive are probably not
> > > supported,
> >
> > Actually this is possible.
> 
> I know it's currently possible, but should it be? It doesn't seem like a
> good idea, what with the queue bypassing and all that.

Delayed copies will also skip the queue, the only difference is that in that 
case we need to re-upload files from the restricted librarian.

At some point I want to be able to let PPA owners who have Ubuntu upload 
privileges to use PPAs as staging posts, and then copy their packages into 
Ubuntu.  If the package has ancestry, there's no reason why it should hit the 
queue at all, unless the series is frozen in which case it hits 'unapproved' 
of course.

Cheers
J