We now have the autoload recipes and initial factories checked in. Next, we will be building the actual encapsulated RPMs. We will start by using mirrorball to assemble source packages for some RPMs; enough to be the build requirements for running Conary to encapsulate RPMs. Normally, mirrorball hands off to rMake to do the build; we'll skip that building part. We'll hand-build the encapsulated packages in the chroot environments into the bootstrap repository.
We won't cook the autoload recipes and factories into binary packages yet. Once we do that, we have to cook them for every change, so it's just easier right now to leave them in source form. With those bootstrap imports finished, we'll be able to use mirrorball normally do build packages and groups. The group structure will look a lot like you might have seen in the CentOS import before, though instead of group-rpath-packages for the Conary-related tools, we'll probably go with group-conary-packages (unless it causes too much churn for reasons we haven't though through yet). As I mentioned before, in early encapsulation we built our first set of bootstrap packages is nearly complete development environments in order to calculate python and perl requirements, and wrote a script to determine that normal buildRequires for each package so that we could build them with rMake in chroot environments and still calculate those python and perl requirements correctly. We won't run that script this time, because we won't calculating those requirements. That will let us move on to the real import faster. Once we start building packages, we'll run into problems. We will normally fix them by committing changes to the factory-capsule-rpm package, not to individual source package that are affected. That means that the factory work can be shared across OSes and versions easily. We'll eventually put the factories into Git repositories, and use Git branches to share them across multiple versions of encapsulated OS imports, which means that most of our fixups need to be done only once. Many of the problems we'll run into will be discovered after one round of package importing when we are trying to build groups and discover that the encapsulated packages are not conary-dep-complete. It will almost certainly take several passes through the errors we see when trying to build groups, rebuilding affected packages, before we can build groups successfully. After we can build groups, we'll be able to do things like import updates; right now, we're sticking with the initial release of F20 with no updates. We really want all the initial packages in the repository to make it easy to "adopt" systems that were installed from the original media. Mirrorball will drive that update process. >From time to time during the update process, either package or more likely group builds will break. At that point, we have to investigate why and remediate. For CentOS and RHEL, that has generally happened with every point release, and occasionally with updates. With Fedora, it's like to happen more often because Fedora allows more change within a release than RHEL or CentOS. _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
