Jeremy Katz wrote:
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
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,
OK, we'll just have to override this function then.
> * For any type of extra configuration or external configuration
> non-kickstart), would it be possible to have variables such as
> 'build_dir', 'yum_cache' and '_instroot' defined in (for
> __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.
Regardless though of my personal opinion in whether you are right or
wrong here -I do think I agree to some extend-, it is a requirement for
Revisor to be able to use the function directly from livecd-tools, as we
cannot change the installroot for the yum object once we've created it,
but since we don't know yet what is the _instroot/builddir
livecd-creator is going to come up with, we have a chicken-and-egg
problem. If you know how to solve that in another way that we can work
with, or give us some pointers other then to create another yum object,
I'll be more then happy to look into implementation.
Overriding the builddir and the instroot just isn't that
To livecd-tools it may not be of any interest, however to us, it is.
they're temporary bits that are blown away on errors, after
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())
The cachedir arg gets "/yum-cache" appended, which could be used by
Revisor but I'd rather have it not append anything (to cachedir; I
understand why it appends to builddir) -would that be possible?
Jeroen van Meeuwen