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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
