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
2) BETANAG is a constant in anaconda itself
Again, you get to modify anaconda files in %post/%triggerin
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.
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.)
Bill
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
