----- Original Message -----
From: "Mike McLean" <mikem(a)redhat.com>
On 10/18/2013 02:07 AM, Anthony Towns wrote:
> changeBuildNamespace?
> Would it make sense for that to be addBuildToNamespace and
> removeBuildFromNamespace instead?
I.e. allow builds to occupy multiple namespaces?
Yeah, that's what I was thinking.
'addBuildNamespace' might also make more sense for the null to namespace step; ie
def addBuildNamespace(build, ns):
if buildNamespace(build) is not None:
raise "Build can only have one namespace"
def removeBuildNamespace(build, ns):
assertPerm('admin')
if buildNamespace(build) != ns:
raise "Build is not in that namespace"
It's possible to do so, but we'd have to move the uniqueness
constraints
out of the build and rpminfo tables and into some sort of parallel
buildlabel and rpmlabel tables.
How does uniqueness of filenames work given namespaces? Does the namespace get added into
the path to the rpms, or some unique id (hash? build id?)? If it's the namespace, I
guess changeNamespace moves files around too?
> 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
> ?
Interesting, I was about to say that for the first case namespace was
irrelevant (and it is given the current set of patches). However, I
wonder if you're suggesting that foo::kernel and baz::kernel should be
treated as entirely separate packages in terms of showing in such a
query. My gut feeling is we don't want to do that.
Main question is how the heck do you figure out which namespace a build is coming from and
then reference it back when you're using the command line?
For non-null namespace tags, you could deduce it from the tag, so you'd see:
Build Tag Built by
---------------------------------------- -------------------- ----------------
foo-1.2-3.el6 rhel-6 alice
bar-3.14-159 myproject bob
and say 'okay, that's foo-1.2-3.el6 from the rhel namespace, and bar-3.14-159 from
the mycompany namespace', and then run
$ koji buildinfo mycompany::bar-3.14-159
You'd have an extra step working out the namespace from the tag though, unless you
could run something like:
$ koji buildinfo --ns-for-tag myproject bar-3.14-159
If you had a scratch build tag with null namespace, you could have worse problems though:
Build Tag Built by
---------------------------------------- -------------------- ----------------
foo-1.2-3.el6 scratch alice
foo-1.2-3.el6 scratch alice
foo-1.2-3.el6 scratch bob
foo-1.2-3.el6 scratch carol
foo-1.2-3.el6 scratch bob
foo-1.2-3.el6 scratch alice
If Carol's happy with her build, how does she look that up from the command line
without hitting one of the other builds?
I was thinking a 'Namespace' column would solve the problem nicely; but it
doesn't really solve it for null-namespace builds, and would run into problems fitting
in 80 characters.
A few ideas:
- for null-namespace builds, maybe 12345::foo-1.2-3.el6 where 12345 is the buildid would
work? are namespaces allowed to begin with numbers?
- maybe always displaying builds as ns:nvr whenever the namespace isn't the default
ns would be reasonable?
- if so, maybe letting the client choose what 'their' default namespace is would
make it a bit more palettable
- if so, maybe some way of saying "my default namespace is actually rhel +
projectA" and having koji enforce that no projectA build/rpm clashes with a rhel
build/rpm would be useful; likewise for rhel and projectB perhaps, while projectA and
projectB builds could still clash.
Cheers,
aj
--
Anthony Towns <atowns(a)redhat.com>
Red Hat Release Engineering