Re: Looking at the payload from an addon
Pat Riehecky <[email protected]>
| Newsgroups | gmane.linux.redhat.anaconda.devel |
|---|---|
| Message-ID | <[email protected]> |
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