Copr integration

[Mike McLean]

On 10/21/2013 01:42 AM, Anthony Towns wrote:
>> 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?

For RPMS, we have a uniqueness constraint (n,v,r,a,*) in the rpminfo
table. With namespaces, we add namespace_id into the mix.

Yes, rpminfo namespace should match the corresponding build.

For archives (e.g. jars, images), there is no uniqueness constraint on
the filenames.

> 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

I think we'll probably need to have the interface display the namespace
when it is not the default. E.g.


Build                                     Tag                   Built by
----------------------------------------  --------------------  --------
foo:mypkg-1.2-3.el6                       proj-A-el6            alice
baz:yourpkg-3.2-1                         proj-B                bob
yum-3.2.29-17.el6                         rhel-6.1              admin

> 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?

I'm not sure about overloading the namespace prefix. Though if we do,
maybe put a '#' in there also.

Certainly using the build id in some form is a bulletproof way to ensure
uniqueness.

> - maybe always displaying builds as ns:nvr whenever the namespace
> isn't the default ns would be reasonable?

Yeah, I think long form display for non-default namespace is the way to go.

> - if so, maybe letting the client choose what 'their' default
> namespace is would make it a bit more palettable

Well maybe. I see the appeal, but it gets tricky when the standard
becomes context dependant.

> - 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.

Interesting. I don't see a sane way to enforce that as a database
constraint, but I guess it would be possible to enforce in the hub code.