On 10/11/2013 01:09 PM, Miroslav Suchy wrote: > Speaking for Copr: > Each new project in Copr, should create new namespace in Koji. So if two > identical NEVRA from two different namespaces would not raise conflict, > and two identical NEVRA from one namespace would raise conflict, then it > is everything I need. > Well - beside some API for namespaces. I need some API to create > namespace and some API to assign relation between koji tag and namespace.
New hub calls from the current namespace patches: addNamespace, removeNamespace, listNamespaces, changeBuildNamespace, getNamespace (and more on the way) > BTW can you elaborate on relations between namespaces, koji tags and > build targets and build tags? Especially the last two are kind of fuzzy > for me. 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. Tags will also be allowed to have a NULL namespace. In that case, builds for targets with that tag as the destination will go into the default namespace, but the tag will accept. 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. One more thing I should clarify. I'm not planning on having namespaces apply to tag names themselves, just to builds. Tag names will still be unique. The associated namespace is just a bit of tag configuration that controls the two effects listed above. However, I'm somewhat open to arguments to the contrary. > And speaking completely general now: > I find quite useful if NEVRA uniqueness is enforced per koji tag. It > caught building from incorrect location in Katello and Spacewalk Koji > for several times. I'm not quite sure what you mean, but it sounds like this could be accomplished by creating a new namespace for the tag. As for building from incorrect location, I'm not sure how the namespace restriction is going to solve that. However, that sounds like something that a policy rule could solve. Maybe you could give little more detail? > But I find quite annoying that I could not build package with the same > NEVRA in Koji where build other teams and projects (unrelated to mine). > Those packages was build in different tag. They landed in different yum > repos. I do not trust that different team, so I do not want to re-tag. I > just want to build another package with the same NEVRA. 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. Many of the use cases I can think of that namespaces solve could also be solved with dist tags or simply release bumps. Seems like a lot of it boils to to version vanity -- an irrational desire to have the NEVRA be a particular value. On the other hand, there probably are cases where the NEVRA needs to be a particular value. There probably are cases where there are legitimate reasons for overlap. Since the question was raised, I'd just like to clarify our reasons. > Of course - others can have different opinion. So if this can be driven > by some option in configuration file, then it would be cool. Especially > whether default namespace will be Foo or Null. Sure. I built the NVR uniqueness into Koji early on, before it was even Koji, because NVR overlap was big hassle and could cause confusion, at least in our use case. I believe my changes are flexible enough to allow folks to be strict if they want, without requiring them to be. 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. -- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
