On 12/30/2011 01:02 AM, Larry Brigman wrote:
That sounds good. I have built ISO's with upstream packages that weren't available even from EPEL.
This is part of what we're doing in my situation. There are a lot of custom ERP/office automation, CAD, etc things that no distros include just yet, *and* the customer uses the systems for showroom stuff so rebranding (at least surface stuff that's readily visible) is an issue as well. There is also the matter of our Fluendo codecs and media things that can't go into a community distro because they have to get paid for somewhere along the way, and the applications that are being ported to PostgreSQL 9.1 from evil-empire type software...
Some of this goes beyond what ks can do alone, and having clean isos that the users can carry for demos and things go a long way to reducing confusion and manpower needs (sales != devepment types...).
I take it the tools are in anaconda-runtime or their dependency set?
> Is there some documentation on building a custom iso spin? > I would also like to be able to drive the tools. What does that mean 'drive the tools' ?I have used buildinstall from anaconda-runtime package but trying my same recipe that I used from Centos 5 doesn't work. So I wonder, if I was giving the correct input to the tool or if the project has a set of scripts that provide that input in some manner that would better document the tools?
This command works so long as the ../Packages/ directory actually has all the packages necessary for the system to work correctly. This boots straight to the installer, no livecd stuff, and gives you the chance to install whatever is in Packages.
A command very similar to this is what gets fed automatically to /usr/lib/anaconda-runtime/buildinstall by other tools.
/usr/lib/anaconda-runtime/buildinstall --version 6 --brand $COMPANY --product $PRODUCTNAME --release "Tester" --output /home/iwao/remaster/ /home/iwao/remaster/Packages/
One quirk is you still have to do this as root. Looking for a way around that. Using revisor you have to disable selinux as well (eh?). So there are some weird things that I feel were never worked out properly because the drive to "virtualize everything!" got in the way of writing for proper system segregation at the user level. So this root/disable SELinux thing is likely a development oversight that was never straightened out, but may not be all that hard to fix.
I'm curious what the CentOS build infrastructure looks like. Fedora's is quite robust/complex but works pretty well considering the things they put it through from time to time.