[Fedora-livecd-list] Refactoring livecd-creator and providing an API

[Jeroen van Meeuwen]

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
> 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.  
> 

OK, we'll just have to override this function then.

>> * 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. 
> 

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 interesting --

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 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())
> 

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?

Kind regards,

Jeroen van Meeuwen
-kanarip