On Thu, 2016-05-12 at 12:58 -0400, Colin Walters wrote: > I wanted to start a quick architecture discussion here based on > https://github.com/projectatomic/fedora-productimg-atomic/pull/3 > > I'd like down the line if more decisions like this were based on > the *content* and not the productimg, because it's more generic. > It'd be quite possible and reasonable for someone to regenerate > the ostree commit with documentation downstream. > > Similarly, people composing Workstation systems are probably > going to include docs. > > In a network install scenario, I know this gets a bit more complex, > as we would need to fetch some metadata (which could be the ostree > commit object) to determine this. Yep - at least in the case of the single language mode you basically need to decide before the GUI shows up as you are disabling parts of it. If for example the user needs to manually setup the network and installation source first its kinda to late to retroactively disable the language configuration spokes that have already been shown to the user and that might have been interacted with. Well, *theoretically* it could work in reverse - you start in single language mode but turn it off once you can read the metadata from the network. But that would still mean you could not change the installation language, just the installed system language & there might be some issues with this as we currently don't change spoke visibility once a hub has been loaded. > > But in the case of an Atomic Host ISO where we embed > the ostree content, there shouldn't be any network bootstrapping > issues; > we have the content in the ISO. That way things would similarly > Just Work for a Workstation case The single-language mode can also be triggered with the inst.singlelang boot option - so I guess if you know you want to run the installation in single language mode when you create a media you could make sure that boot option is used when booting from it. > > In order to make this work, we'd need to teach rpm-ostree > to write out well-known metadata in the ostree commit, and > change Anaconda to look for it. > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
