Re: Composing custom distros & anaconda

[Jeremy Katz <katzj redhat com>]

On Mon, 2009-01-05 at 16:27 -0500, Bill Nottingham wrote:
> I was working on composing a custom distro based on Fedora 10,
> and I kept running into various minor issues that made the process
> not work as well as I'd like. I'm cataloging these here, in case
> I'm missing something obvious that I should be doing instead of
> what I did.
> 
> 1) Fedora and RHEL installclasses are directly in anaconda
> 
>    To override/remove them, you get to remove them in a custom
>    package's %post, and also with a %triggerin on anaconda

This has always been the case -- if you want something more custom, the
right path is likely a product.img being built for your tree and dropped
into images/

> 2) BETANAG is a constant in anaconda itself
>    Again, you get to modify anaconda files in %post/%triggerin

BETANAG was (historically) more about anaconda being beta than anything
else

> 3) anaconda and pungi don't support identical repo definitions
>    To override packages in the base repositories, I can set up
>    a local repository with packages that obsolete the base repo
>    packages, and set cost appropriately (or --exclude/--include.)
>    anaconda ignores all of this when building install images,
>    causing me to have to go to dirty hacks to not pull in
>    packages I don't want.

You mean buildinstall here? 

> 4) repo editing, and the 'built-in' repos
>    Say you're composing a custom distro, with a custom comps file, etc.
>    How do you set up the post-install repo files for yum correctly?
>
>    Your choices are:
> 
>    1) use the 'upstream' Fedora repos. In which case you have to tell
>       it to ignore the group file, and anaconda's built-in repo support &
>       repo editing will point to/enable those repos by default
>    2) mirror everything into your own custom repos based on what you're
>       building with pungi. This is waste of space, and also means that
>       you have to make a custom <foo>-release package that points to these
>       custom repos... before you even build them. (And if you're doing
>       the normal spin, fix, spin, fix cycle, you get to keep
>       resyncing/recreating that tree.)

If you're really doing something custom, I'd expect you don't want 1 in
any case.  The third option is that the repodata can point to an
alternate baseurl iirc; so then you could just have a set of repodata
that then points to a separate repository of packages.  But I don't
remember the createrepo invocation needed to make that happen, I just
remember having the discussion with Seth about the possibility of doing
it in the context of making a few things nicer with koji

Jeremy