----- Original Message ----- > From: "Mike McLean" <[email protected]> > On 10/11/2013 01:09 PM, Miroslav Suchy wrote: > > Speaking for Copr: > New hub calls from the current namespace patches: addNamespace, > removeNamespace, listNamespaces, changeBuildNamespace, getNamespace > (and more on the way)
changeBuildNamespace? Would it make sense for that to be addBuildToNamespace and removeBuildFromNamespace instead? Does it actually make sense to let you remove a build from a namespace? If you have namespaces foo, bar, baz, and build pkg-1.2-3.el6 separately for both foo and bar, doesn't something like: changeBuildNamespace pkg-1.2-3.el6 foo baz changeBuildNamespace pkg-1.2-3.el6 bar foo violate the 'uniqueness' constraint for pkg 1.2-3.el6 in foo? At one point it had hash X, now it has hash Y; it could also create conflicts where pkg-1.2-3.el6(from foo, now in baz) is still in foo-build which is meant to be restricted to namespace 'foo' packages. I think it would make sense to allow addBuildNamespace pkg-1.2-3.el6 foo baz if the build of pkg-1.2-3.el6 in foo is adequate for baz's needs, to save unnecessary rebuilding though. > Associating a namespace with a tag is coming and I expect to post that > early next week, or maybe earlier if I can find the time. The tag > namespace value will serve two major functions. > First, when building, the namespace for the build will be chosen to > match that of the destination tag from the build target used to build. > Second, when tagging a build, the system will require that the build > namespace matches that of the destination tag. How about tag / namespace inheritance? The use case I'm thinking of is Alice and Bob both want to build a complicated upstream project on top of, say, RHEL 6 in the same koji instance. So Alice wants a build tag alice-foo in namespace 'alice', that inherits from rhel-6.4, and Bob wants bob-foo in namespace 'bob' that also inherits from rhel-6.4. I think that sounds like it would work sensibly. How are namespaces reflected in all the standard existing calls, like getBuild? If Alice and Bob both do different rebuilds of rsync-3.0.6-9.el6, which is also in rhel-6.4, how do you make sense of: $ for tag in rhel-6.4 alice-foo bob-foo; koji latest-pkg $tag rsync; done $ koji buildinfo rsync-3.0.6-9.el6 ? > Actually, I'm a little unsure about the NULL namespace business. It > might become the future of scratch builds, or it might just go away. Being able to promote a scratch build to a legitimate build would be pretty nifty. If 'addBuildToNamespace' existed and validated the uniqueness constraints, I think that would even work. It would also mean that you could make your workflow be "scratch build; test; scratch build; test; scratch build; test; promote to legit build" and not have to bump the revision number every time the tests fail. > One more thing I should clarify. I'm not planning on having namespaces > apply to tag names themselves, just to builds. +1 > The argument I encountered was that having overlapping NEVRAs in the > wild is confusing. I can certainly see that point, but I still think > there is worth in namespaces. I'd just like to get a clearer argument > for why, other than flexibility for its own sake. I'd put it down to making it easy to avoid coordination problems. You can do it with %dist tags, but only if you ensure everyone has a unique %dist tag, and doesn't accidentally do builds with the %dist tag set wrong. > If folks don't want namespaces, they don't have to add them. I think > I'll even add a DisableNamespaces option in the hub config. +1 I'd presume both creating a new namespace and adding builds to a namespace would be controllable by permissions / hub policy too. Cheers, aj -- Anthony Towns <[email protected]> -- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
