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? 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. I'm not quite grasping the utility however. Though, to be fair, we haven't exactly sorted out all the use cases. I'll have to think more about it. > 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. Well, to swap two same-NVR builds between two namespaces you'd need a middle step, e.g. foo::pkg-1.2-3.el6 -> NULL baz::pkg-1.2-3.el6 -> foo foo::pkg-1.2-3.el6 -> baz Otherwise the first operation would violate uniqueness. Whether something like this is a good idea is a different question. You have a good point about the tag condition. We should probably check for such violations and at least warn about them when changing the namespace. > 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. Right now the main use case for distinct on-null namespaces is for independent users in a copr-like system to have their own namespace so they don't have to deal with conflicts with other independent users. A secondary use case is to simply allow the system to tolerate such overlaps when they are necessary. For example, your company/project could have historical nvr/nvra overlaps that you need to be able to import in parallel. Note that mixed-namespace builds can coexist in several ways. First, a null-namespace tag will accept builds of any namespace. Second, a tag can inherit from a tag of a different namespace. In particular, I expect it is quite likely that non-default-namespace build tags will inherit from some base os tag that uses the default namespace. >> 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. A tag's namespace setting is not inherited. However, when creating a new tag that has a specified parent, the default namespace is that of the parent. > 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. In the second case (and really any case where a call accepts a single build reference that is expected to be singular), namespaces certainly make for a little complication. First, if you explicitly want a specific namespace, you can prefix it with ::, e.g. foo::rsync-3.0.6-9.el6. This is understood by parse_NVR and parse_NVRA, so most calls should just run with it. Absent a namespace specification, the default namespace is preferred when a singular result is expected. Absent that, then the latest one (by build id) is returned. However, a number of calls pass strict=True to get_build() which will cause it to error if the build specification is not unique. >> 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. Yep, it could be handy, and that capability is certainly something folks have asked for in the past. -- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
