> 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....... Yeah, I think you are out of luck with how the code is currently set up. I don't see that the payload is passed to the addon at any point, nor does it appear to be an attribute on any of the things that are passed to the addon. I think you should file a bug about this. It will require adding arguments, but we can do that with *args, **kwargs to not break things. Anyway, you might be able to figure out what payload is in use by examining the system. For example if there's a /tmp/anaconda-yum.conf, we are probably using the yum payload. If there are an awful lot of bind mounts present with very hash-looking names, it's probably the ostree payload. I think if you look around in the payload classes, you'll be able to find identifying marks to look for. You might also be able to look at the log files - we might log what payload class is being instantiated. It's going to take some trial and error, but I think it's the best you can do for now until we get the bug fixed (which would be at least 7.3 at this point, ugh). - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
