launchpad-dev team mailing list archive

[William Grant <me@xxxxxxxxxxxxxxxxxx>]

On Mon, 2009-09-21 at 17:14 +0100, Julian Edwards wrote:
> 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 guess making that connection explicitly is probably better than
comparing names each time. It will make things much easier.

> > > 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?

Hmmm. I suppose that's OK, but it would be nice to indicate in the
displayed name that a DDEB is being overridden/removed as well.

Can't you only accept/deny an entire build anyway?

We also need a way to remove DDEBs explicitly (eg. to NBS them out). I
guess just adjusting lp-remove-package.py to find binaries in the debug
archive directly would work.

> > 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.

The queries are somewhat easier if only the debug archive is included.
If we have the explicit DEB->DDEB linkage table, I don't think it will
end up being much easier to include partner.

> [snip]
> > > > 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.

Direct copies will then need to be taught to respect overrides in the
target archive. I guess that's easy enough, and unrelated.

--
William Grant