On Wed, 2009-11-18 at 16:24 +0000, Julian Edwards wrote: > Michael Hudson wrote: > [snip] > > Separately, we need to decide where a recipe lives. The current > > thinking is > > "https://launchpad.net/ubuntu/karmic/+source/some-package/+recipe/recipe-name"; > > which seems OK to me (we'd have to trust a bit that this recipe would > > build a recipe for some-package in karmic, but that doesn't seem any > > different to say branches today). > > I don't think this is good for a few reasons: > * The URL is too long > * The traversal would fail for a recipe where a source package name > doesn't exist yet > * The recipe is tied to a series. Recipes should be independent of a > series. > * Why have more than one recipe for one package? > > My suggestion is: > /<distro>/+recipe/packagename
Rather than something strange like this, why not allow the SPN to be created at recipe-registration time? That seems substantially cleaner, and it's not as if the SPN namespace is exactly clean even now. > [snip] > > - the issues of accessing private branches from the buildslaves > > scares me a bit, I hope we can avoid worrying about that until some > > time in 2010. > > Yeah, I had only considered the firewall rules from the slaves. > Presumably we'll need a buildd-slave SSH key that can access everything? That's impossible, unless you start doing stuff outside the VM. That sounds like a recipe for trouble. In a later email, you suggested chroots. chroots do not help. They are simple to break out of. The only solution that I see as feasible is doing something rather like P3As: HTTPS with per-branch credentials. I initially considered that buildd-manager should grant and revoke these credentials on a per-job basis, but I guess a branch's buildd key doesn't ever actually need to change. > [snip] > > [1] I guess the fact that these packages aren't signed will bite us in > > the ass somehow or other at some point, but I don't know how much it > > affects how this bit would work. We don't *have* to get the source > > package files into Soyuz via the Librarian I guess. > > Mark S has suggested that we have a single Launchpad key to sign them, > so that if the packages are used outside of Launchpad then people know > where they came from. Where will they be signed? It cannot be anywhere on the slaves. Remember that we already have lots of unsigned sources in LP (mostly syncs), and that hasn't been much of a problem. William. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
