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. -- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
