On Mon, 2007-11-26 at 16:40 +0100, Jeroen van Meeuwen wrote:
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.
I know we've been around and around on this, but I really still don't
see your hang-up over having your own hand-constructed yum object rather
than making use of what's created, used, etc by the API. And I think
that's the crux of your other comments is that you want things so that
you can have your own yum object.
> 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?
That's just done that way because it's how Colin's patch originally did
it. I'm not at all tied to keeping the /yum-cache bit there.
Jeremy