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

[Jeroen van Meeuwen]

Jeremy Katz wrote:
> 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.  

I didn't want to comment on this before but you leave me little choice:

"Has to" is something completely different then "could". No-one even 
suggests you should remove any yum objects or actions from imgcreate. 
Instead I'm asking whether you could provide the means to have 
InstallPackages() use another yum object then it's own.

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

I could try and tell you again it is due to the fact that we do things 
different. I could also try and tell you that there is multiple, 
different ways in which for example package selection from a kickstart 
package manifest could be performed or in which you resolve the 
dependencies, but you know that. You also know Revisor provides the 
options to the user to choose a specific type of behaviour -we've told 
you many times before.

The other way around though: What is so much better about the yum object 
  in, or the API itself, that makes you not want to take into 
consideration using a yum object provided by external tools?

Kind regards,

Jeroen van Meeuwen
-kanarip