----- Original Message -----
From: "Mike McLean" <mikem(a)redhat.com>
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 <atowns(a)redhat.com>