Difference between revisions of "Koji Testbed"
From PDP/Grid Wiki
Jump to navigationJump to search| Line 71: | Line 71: | ||
* packages, in the first sense as described above | * packages, in the first sense as described above | ||
* packages, in the second sense as described above | * packages, in the second sense as described above | ||
| + | * architectures, such as i386 and x86_64 (in fact, only those in our case) | ||
* groups (we'll get to those later) | * groups (we'll get to those later) | ||
* external repositories | * external repositories | ||
| + | * build targets (source or destination) | ||
* other tags called �parents� | * other tags called �parents� | ||
The second most confusing word in Koji context is the word 'parent' and, along with that, the entire concept of inheritance. In the biological sense we can't choose, change, or add parents, but tags have no such limitations. While normally we inherit from our parents after they pass away, tags inherit everything from all of their parents (and parents' parents) immediately. Remember: in the graphical displays, Koji shows parents down and to the right in the inheritance tree. | The second most confusing word in Koji context is the word 'parent' and, along with that, the entire concept of inheritance. In the biological sense we can't choose, change, or add parents, but tags have no such limitations. While normally we inherit from our parents after they pass away, tags inherit everything from all of their parents (and parents' parents) immediately. Remember: in the graphical displays, Koji shows parents down and to the right in the inheritance tree. | ||
| − | The builds are done against targets, which have source and target tags | + | The builds are done against build targets, which have source and target tags. The way this works in a nutshell is as follows: |
| + | * the user issues the build of a package (1st sense) for a specific target | ||
| + | * the target's ''build tag'' is chosen to create a build root | ||
| + | * dependencies are resolved, hopefully | ||
| + | * the build runs, and if all is well this results in a new artefact (a package in the second sense) | ||
| + | * this package is tagged with the target's ''destination tag'' | ||
| − | + | Resolving dependencies and setting up a build root works by combining external repositories and packages with the build tag, and installing a meta-package with 'yum groupinstall'. This is where the concept of ''groups'' comes in. There are two groups for the different phases of a build: <code>srpm-build</code> for the creation of source RPMs and <code>build</code> for the actual build. | |
| − | + | The groups as created in koji contain only package names. | |
| − | ( | + | === Current setup === |
| + | |||
| + | Fedora releases are built one on top another, and using inheritance makes perfect sense. But there is a catch. Builds, a.k.a. packages in the second sense, are inherited just the same. As are external repositories. We've experienced that our build tag for Fedora 18 collected everything from Fedora 17 and 16 (when we started), including all the repositories. This went crazy. | ||
| + | |||
| + | The solution is to be careful about what we inherit. The current setup is displayed best by the following pictures: | ||
| + | |||
| + | $ koji list-tag-inheritance --reverse f16 | ||
| + | f16 (7) <- contains ONLY packages in the first sense | ||
| + | ??f17 (9) <- so does this, by inheritance | ||
| + | ? ??f17-candidates (33) <- this is the "build target" "destination tag" | ||
| + | ? ??f17-release (25) <- this is used manually to mark a package (second sense) ready for shipping with mash | ||
| + | ? ??f17-testing (26) <- idem, but the for the 'testing' repo | ||
| + | ? ??f18 (27) <- only packages, first sense | ||
| + | ? ? ??f18-build (30) <- the "build target" "build tag"; this has architectures and external repos | ||
| + | ? ? ? ??f18-candidates (31) -< the "build target" "destination tag" | ||
| + | ? ? ??f19 (34) | ||
| + | ? ? ? ??f19-candidates (38) | ||
| + | ? ? ? ??f19-release (43) | ||
| + | ? ? ? ??f19-testing (44) | ||
| + | ? ? ? ??f19-build (36) | ||
| + | ? ? ??f18-release (39) | ||
| + | ? ? ??f18-testing (40) | ||
| + | ? ??f17-build (32) | ||
| + | ??f16-release (24) | ||
| + | ??f16-testing (23) | ||
| + | ??f16-build (45) | ||
| + | |||
| + | And this one: | ||
| + | |||
| + | $ koji list-tag-inheritance f19-build | ||
| + | f19-build (36) <- the "build target" "build tag" | ||
| + | ??f19 (34) <- package names only (first sense) | ||
| + | ? ??f18 (27) <- all the way | ||
| + | ? ??f17 (9) <- down to | ||
| + | ? ??f16 (7) <- here | ||
| + | ??f19-basedeps (35) <- these contain the 'groups' | ||
| + | ??f18-basedeps (28) <- actually inherited from | ||
| + | ??f17-basedeps (10) <- here | ||
| + | |||
| + | A build for F19 ends up in the tag f19-candidates. From there, it needs to be manually moved. If it is a build dependency for other packages, it has to go to f19-build. Otherwise, it eventually goes to f19-testing and from there to f19-release, or directly to f19-release. A rotten product should have its candidacy stripped and ends up with no tags. In any case, no package should remain a candidate for too long. | ||
| + | |||
| + | Because the *-builds don't inherit from each other, we have no pollution of external repositories or old builds for new Fedora releases. | ||
=== Steps to follow if you need to do this from scratch === | === Steps to follow if you need to do this from scratch === | ||
