I had a half-baked idea this morning. I wonder if it would be worthwhile to make the payloads more modular so that you could put together an anaconda image that only supported deb packages for exampel. Right now any new payload needs to be added to pyanaconda/anaconda.payload along with the logic for selecting it.
Instead we could change payloads to a registration model, like installclasses, and then call their probe() functions (with some kind of weighting) and let them decide which one to use.
Ignoring the complications from different UI support :) this would allow new methods to be dropped in by 3rd parties (like addons) without having to modify the core anaconda code. It would also be possible to split out the individual payloads into subpackages, allowing for simpler installer images.
Ignoring the complications from different UI support :) this would allow new methods to be dropped in by 3rd parties (like addons) without having to modify the core anaconda code. It would also be possible to split out the individual payloads into subpackages, allowing for simpler installer images.
I think this would definitely be worth investigating.
- Chris
On Mon, Dec 07, 2015 at 10:19:57AM -0800, Brian C. Lane wrote:
Ignoring the complications from different UI support :) this would allow new methods to be dropped in by 3rd parties (like addons) without having to modify the core anaconda code. It would also be possible to split out the individual payloads into subpackages, allowing for simpler installer images.
Seems like a good way to encourage innovation for things like the ostree/atomic payload feature.
Ignoring the complications from different UI support :) this would allow new methods to be dropped in by 3rd parties (like addons) without having to modify the core anaconda code. It would also be possible to split out the individual payloads into subpackages, allowing for simpler installer images.
Okay, here's a more substantial comment: As part of this, we'll need to go through and make sure the payload API is really what we want, hide stuff that really should be hidden, perhaps break parts out into separate files and APIs, etc. I think this is one part of anaconda where we've always been able to get away with being a little sloppy because we knew it'd only ever be us looking at it.
- Chris
anaconda-devel@lists.fedoraproject.org