On 12/03/2015 03:13 PM, Chris Lumens wrote:
I'm working on an addon where I'd like to do a bit more introspection on the
payload within the addon itself.
So I started working on the kickstart aspect and ran into a bit of
confusion.
For what I'm doing I need to act a bit differently if the payload is yum vs
dnf vs ostree. However, I don't see a way for me to look at the payload
object from within the kickstart functions.
Did I miss where I can get to it? Any suggestions?
Can you post the code you've got so far somewhere? Also, what release
is this?
My release is EL7.2, anaconda-21.48.22.56-1
As for code, I'm a bit light on worthwhile bits.... I can share what
I've got, but mostly it is just a hacked up version of
org_fedora_hello_world with me logging the content random things.
From the comments in pyanaconda/addons.py ( line 117 and following )
I'm looking at my options from within the addon's setup function. It
seems the most direct place as the install isn't started.
>From brief looking around, I don't see a great way of getting at payload
from without a subclass of AddonData. To me, that seems like an
oversight that we could take care of. We are passing around storage,
ksdata, and instClass after all.
Ultimately, I'm trying to get access to whatever implements
pyanaconda.packaging.Payload in the installing system. From my reading
of pyanaconda.install ( around line 260 ) it doesn't look like payload
is exposed to the addons.
I'm not overly familiar with the code base or data model, but as you
said it does feel like a bit of an oversight. With that in mind, fixes
without breaking things may be an issue as the setup function args would
have to change or gain an additional property.......
Pat
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
