Johnny Hughes wrote:

We can no longer release the scripts in their entirety as we have a build system with logins / keys, etc. that are referenced in the scripts.

Before you ask ... the buildsystem is based on mock and plague, available via KBS CentOS-Extras.

I can see if I can sanitize parts of the script to make it work in a similar way to the c4 one and publish that, but with EL5 (and fc5/fc6/f7) building in mock and some kind of centralized buildsystem (plague / koji) ... reproducing these kind of scripts is going to get much harder.

I'll try to do that after the centosplus kernels that I need to build for c4 and c5.

Thanks for full answer.

May be a good idea to create howto on CentOS Wiki of building discs process to give users possibility of creating CentOS based distributions for highly specialized purposes?

Karanbir Singh wrote:

short answer: use pungi ( https://hosted.fedoraproject.org/projects/pungi )

if there is enough interest, I can build and host the pungi rpms on centos.org itself - we can talk to Jesse and see how he feels about that, cant see there being any issue.

No, thanks. I almost wrote own script to resolve my tasks.

P.S. As I know, impossible to build RHEL5/FC6 distribution with latest version of pungi - it's requires latest yum package (and/or other) packages from FC7.

On 5/18/07, Nikolay Ulyanitsky lystor@lystor.org.ua wrote:

May be a good idea to create howto on CentOS Wiki of building discs process to give users possibility of creating CentOS based distributions for highly specialized purposes?

While I like the idea of folks using centos for custom projects and everything, I'm not sure I'd call this a 'good idea' following the oracle fiasco. It's easy enough to create kickstart files and otherwise customize installs. I'm not so sure I like the idea of centos becoming a meta-distribution to help spawn other distros. This dilutes the community and divide the effort and momentum behind centos.

Preface: My opinions here are my own, and may/may not reflect that of the distro blah blah.

On 5/18/07, Ray Van Dolson rvandolson@esri.com wrote:

I dunno that I'd feel too concerned about this. Anyone with the wherewithal to create and sustain development of a distro will be able to figure out all these steps on their own no doubt. After all, you guys got CentOS going didn't you? :)

Right, and those folks are just as welcome to rebuild from upstream as we do. I don't have any issue with folks doing that at all. My primary concern comes from the support/branding side of it. If I create some half-baked rebuild of centos and leave the centos naming and such in (because I followed a cookie cutter recipe and was lazy and/or didn't know how to) anyone who uses that distro will have a bad experience with 'centos', which will reflect poorly on us even though we have no control over that build.

In a similar vein, I'm quite happy with the Trixbox folks. They use centos as a base for their asterisk stuff and I'm very glad that they chose us; folks seem very happy with it. At the same time, when their users show up here on the list, or on irc saying they're using centos and having a problem with php 4.4.x or some other newer version that we don't ship, it can become difficult to clue them in on what's going on.

The average joe might be able to follow the instructions/tips and roll their own CentOS based distro, but I would be surprised to see it pick up steam unless they were truly motivated / competent in which case they probably wouldn't need the instructions in the first place...

And if they release something that fails, how do we migrate their users back in after their customizations, or reassure them that it wasn't really centos they're unhappy with....

I think it'd be interesting to have instructions available for at least replacing / upgrading the kernel on the installation CD's.

I do also, but I'd take a cautious approach and use the centosplus kernels or security updated kernels first, not a vanilla rebuild.

On Fri, 18 May 2007, Les Mikesell wrote:

So... Is rpath the way to go for specialized stuff?

Yes. Off you go ... Bye.

Karanbir Singh wrote:

...

version. Then instead of a million specialty distributions, you just need repositories where all the parts are available.

the anaconda docs, basic as they are, are trivial - and the process to recreate the distro tree ( which is not what the question originally was, the op only seems to want to know howto redo the isos ) - is very simple, you need to make 1 call to buildinstall - and that will give you the command line you need to run with.

Les, I think your email was based more on what you dont know about the installer now, than anything else.

Actually it's based on a glance at www.distrowatch.com and a bit of bitterness about having each of the ones I've tested unnecessarily break things that work elsewhere.

And yes, its possible _now_ to have repositories enabled at installtime, so you only really need a very small footprint of a distro really, everything else can come in install-time from various places, including the distro media itself hosting multiple repo's is trivial.

I wouldn't mind a two-step process where you install a tiny base, then boot it and give it the list of repositories and packages. The piece I still think is missing is the way to export your current list of packages and a community forum to hold the lists, descriptions and specialized packages. Someone who thinks they've built something useful should be able to push a button to share it, letting other people automatically duplicate it from existing supported packages instead of having to roll a new install cd or vmware image each with new support issues.