[CentOS-devel] custom iso spin

夜神 岩男 supergiantpotato at yahoo.co.jp
Fri Dec 30 23:21:19 UTC 2011


On 12/31/2011 05:47 AM, Karanbir Singh wrote:
> On 12/30/2011 04:25 PM, Johnny Hughes wrote:
>> We have a custom build system.  It uses a beanstalkd workqueue to submit
>> packages to mock and can scale up or down as required and submit
>
> Just to add a few more bits :

> The entire system is called 'reimzul'
>
> As soon as I have got the basic functional stuff in place, and some docs
> around it I'll have it up in a git repo where people can clone and join
> the fun.

> Bit of a brain dump, but there you have it.

Thanks! That was informative, and it sounds like I'm reinventing the 
wheel, or at least a few spokes. Currently I've got a small automation 
of mock, signature, placement and repo creation.

When it comes to custom applications or things just not found anywhere 
else I have a script per application that pulls stable/specified source 
from a tree, scrubs out the fluff or shuffles things around to be the 
way Linux people are accustomed to, touches the standard bits of the 
spec (of course sometimes this isn't possible to do properly), and puts 
an srpm into the directory the mock script will reference. At first I 
thought this would be a pain to maintain, but its easier than 
maintaining spec files and init scripts anwyway, and saves me time (the 
goal).

So generally, from custom code to combining with standard srpms to 
producing a complete repo is not an issue -- and this isn't such a hard 
problem for a single distro anyway.

What I need is a way to move from a complete repo to an install ISO. I'm 
completely missing this step, and suck at doing it manually so need to 
learn more in any case. Doing a livecd isn't a big issue, I just don't 
know much about how to call the anaconda scripts reliably to where I can 
simply pick a repo and wind up with a complete install image and not a 
livecd when necessary.

Beyond that I want to make a way to split the repo list, so I can 
maintain a core repo and then add accessory repos that are segregated 
when they conflict greviously with one another (which is the problem 
with things we have now with some base subsystems like Python3, or 
Postgres 8.4 vs 9.1 specific things that we haven't figured out how to 
make play nicely together, etc.). This issue might parallel some of the 
issues you face maintianing multiple versions of the standard distro.

I am very interested to see whatever you guys put on git. If the shoe 
fits, I might wear it myself and roll my effort into enhancing yours. 
Package management is a pain -- enormously easier than it was in the mid 
90's (when we didn't really have packages yet... hehe) -- but still a 
bit of a pain.



More information about the CentOS-devel mailing list