On Thu, 2007-11-22 at 03:19 +0100, Jeroen van Meeuwen wrote: > * In the 'image.InstallPackages()', would it be possible to not use the > yum object provided by livecd-creator itself? Given that tools built > upon livecd-creator may already have a complete yum object it could be > useful to hand over the yum object to this function
The reason why this is done is because this is _explicitly_ an abstraction. The fact that it uses yum today doesn't mean that it'll use yum tomorrow. Even if we continue to use yum, it makes it so that it's possible to change out the yum API (which is likely to be occurring sooner or later) while not having to make changes to the interfaces of livecd-tools. And yes, I feel very strongly that this is the only way to be able to have consistency in bits built. Otherwise, every user that makes use of the functionality has to implement their own equivalent depsolving, etc. > * For any type of extra configuration or external configuration (e.g. > non-kickstart), would it be possible to have variables such as > 'build_dir', 'yum_cache' and '_instroot' defined in (for example) > __init__() so that once we create a class instance we can override them > with another value? More specifically; if we call ImageCreator.setup() > directly now, there's nothing we can do anymore to point our existing > yum installroot to the 'install_root/' directory under which the > loopback filesystem is mounted. More granular functions all doing > little, very little bits and pieces might help too. The idea, though, isn't that you override every little bit and piece of everything. For one thing, it leads to an API that is a bit out of control and wild. For another, it makes things incredibly difficult to follow and implement. Overriding the builddir and the instroot just isn't that interesting -- they're temporary bits that are blown away on errors, after things are done, etc. The cachedir there's already a way to override at which point, you know what it is (see the cachedir arg to mountImage()) Jeremy -- Fedora-livecd-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-livecd-list
