----- Original Message -----
> From: "Rob Marshall" <rmarshall@xxxxxxxxxx>
> To: "Discussion of Development and Customization of the Red Hat Linux Installer" <anaconda-devel-list@xxxxxxxxxx>
> Cc: "Martin Kolman" <mkolman@xxxxxxxxxx>, "David Cantrell" <dcantrell@xxxxxxxxxx>
> Sent: Wednesday, November 11, 2015 6:09:48 PM
> Subject: Re: Notifying post-install tools about screens seen by the user
>
> This is a great idea and I'd like to contribute the following thoughts based
> on the discussion up to this point.
>
> > From: "Martin Kolman" <mkolman@xxxxxxxxxx>
> > To: anaconda-devel-list@xxxxxxxxxx
> > Sent: Thursday, November 5, 2015 10:59:07 AM
> > Subject: Notifying post-install tools about screens seen by the user
> > Manual installation description file proposal
> >
> > * use the "INI file like" config file format
> > - can be easily parsed from Python using the configparser module
> > - should be also easy to parse from C and other programming languages
> > due to widespread use of INI files
> > * stored in /etc/anaconda/manual_installation.ini
>
> The /etc directory is for running system configuration per the FHS and,
> although a user is choosing configuration information, it is stored
> elsewhere on the system and is no longer apropos after installation and
> first boot processes are completed.
>
> For these reasons I would recommend using Pat Riehecky's suggestion of
> sticking with Anaconda Class Names and putting the files here:
> /var/log/anaconda/interactive/{ClassName}.conf
Still, putting configuration files possibly edited by multiple tools to /var/log seems weirder than
putting configuration files that might not be used ever again to /etc/anaconda.
Also I don't think it is a good idea to have more than one configuration file for this
due to increased parsing & writing complexity.
It would also make it more difficult to check the state manually due to having to check multiple files vs just checking one.
>
>
> > From: "David Cantrell" <dcantrell@xxxxxxxxxx>
> > To: "Discussion of Development and Customization of the Red Hat Linux
> > Installer" <anaconda-devel-list@xxxxxxxxxx>
> > Sent: Friday, November 6, 2015 4:41:07 AM
> > Subject: Re: Notifying post-install tools about screens seen by the user
> > The downside to that is that we'd start overloading kickstart with UX
> > metadata, which seems unnecessary. That and the parser for it is Python
> > only, which would make it difficult for programs like g-i-s. I think we
> > can
> > probably do this with VARIABLE=VALUE syntax
>
> I agree with David that the file should have a syntax VARIABLE=VALUE rather
> than the INI syntax. The variable's scope is handled by the aforementioned
> ClassName.conf convention.
The idea is to use the VARIABLE=VALUE syntax (which is what INI files use)
and use the section headers for scope to have everything in a single file.
>
> It makes sense to note that a user visited a spoke and I agree with the folks
> who have made the case to note whether something was explictly chosen. Using
> the established Time Zone example and assuming Boston is default:
>
> TZ=US/BOSTON
> TZ_DEFAULT=1
>
> TZ=US/NEW YORK
> TZ_DEFAULT=0
This is a bit more complicated - while there is a default (US/New York I think ?)
there are multiple ways of setting a timezone without visiting the timezone spoke:
* successful geolocation lookup sets timezone
* timezone can be set through kickstart
So we can have a non-default timezone even if the user just visited the spoke a then
exited it without changing anything.
Therefore I think it rather makes sense to record that a user:
* visited a spoke at all (ad supposedly saw what's on the screen)
* if the user changed something
- for the timezone spoke example, just noting changes in timezone, time+date and ntp config should be enough
- this could be done in quite a simple way in Anaconda via a decorator around something that's called when user sets the value
As for recording *what* the user selected - I'm not sure that's a good idea, at least for the initial implementation. It would mean at least partially duplicating what kickstart does and makes the stable "API" quite a bit more complex and possibly harder to maintain
in the future.
>
> The explicit benefit here is decoupling consumers of the file from a forced
> knowledge of Anaconda defaults should they change in the future.
>
> --Rob
>
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
