On Fri, Dec 20, 2013 at 11:13:47AM +0100, Mark Trompell wrote: > On Tue, Dec 17, 2013 at 9:07 AM, Philip Cornelius <[email protected]> > wrote: > > I will happily volunteer for this also.. I already have some experience > > using mirrorball to import RHEL (too much time had gone by for this to > > succeed OOTB, for me I got stuck on duplicate package updates) > > I still don't know how I would start, so I hope for some documentation soon. > prepared a local throwaway repository to play with on my box.
Timing is everything... The ex-rPathers have been working to a deadline, so getting the docs updated has to follow the deadline work. I'll give you an idea from my older experience. What Brett tells you (soon, I hope...) will generally trump what I say, as he's been the main one actively doing this for the past few years. But I'll do what I can. Start by checking out all the source from the CentOS6 import. You'll need to add to your conary configuration: repositoryMap centos6.rpath.com https://updates.sas.com/conary/ Then, then the command: conary rq --install-label=centos6.rpath.com@rpath:centos-6-common | grep :source shows what's there. You won't need everything there (we sure don't have to start with sblim, pywbem, xe-guest-utilities, cmpi, conary-cim, iconfig, kmod-open-vm-tools) but checking out everything there will make sure that you have what you do need. conary rq --install-label=centos6.rpath.com@rpath:centos-6-common | grep :source | sed 's/:source.*/=centos6.rpath.com@rpath:centos-6-common/' | xargs cvc co Do that in a separate subdirectory, I suggest... ☺ Also, it's going to take a while. It's a 309318KB changeset you'll download. The bootstrap process, back when I did it for RHEL, involved installing the target system (obviously, a VM works, as does a chroot) in order to use "cvc cook" on that target system to build conary (and other components not in the target OS) into a bootstrap label in a conary repository. One of the things we want to do differently for this import is use the system components instead of conary-private versions. At the time, we wanted to insulate conary from any changes in the target OS that might break it, so we built a minimal python, sqlite, and other packages into a special label just for Conary. Here, we just want to use system components. System sqlite, system python, etc. That means that we don't need to reproduce everything that rPath had previously put on the common label in target platforms like RHEL and CentOS. sqlite, libelf, libxml2, python, etc we don't need. Start with the recipes included with Conary for the bootstrap. Then do the same for other members of the conary family; at least rmake. I'm not sure if others are required at this point. Then you'll need the factory. You can start from the one on the common label that you checked out. The next step will be to use cvc cook on the target system to build the dependencies for building chroots. You can get a start of things to consider by looking at the output of the command: conary rq conary=centos6.rpath.com@rpath:centos-6-common --buildreqs | sed 's/[:=].*//' | sort -u That's the transitive dependency closure, so you don't necessarily need all the same things. That should give things worth looking at until we can get to new mirrorball docs and config... _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
