On 12/05/2017 01:18 AM, Zbigniew Jędrzejewski-Szmek wrote:
Does it mean that just visiting a spoke will cause it to be written
to /etc/sysconfig/anaconda to suppress it in g-i-s?
Or does the user actually have to configure something there?
Just visiting a spoke (already) causes that to be written to
/etc/sysconfig/anaconda, yes. But there are no plans for g-i-s to
actually read this file, as was envisioned by Anaconda developers.
Instead, the plan is to unconditionally skip the language and keyboard
layout selection pages in g-i-s using the g-i-s configuration file
mentioned below. Visiting the language spoke in Anaconda is mandatory,
and if setting keyboard layout were required, that would surely have
already been done in Anaconda.
, so that the initial-setup tool
can suppress specific spokes. Although this functionality has existed
for some time now, the Workstation developers until now failed to
follow up and begin using it. We now intend to make use of this
functionality to suppress Anaconda spokes that are redundant with
gnome-initial-setup.
... and to suppress some spokes in g-i-s, afaiu. So this part should
probably go after the next sentence, so that it's clearer that the
suppression will happen both in anaconda and in g-i-s.
I will delete this sentence, since it is clearly causing confusion. The
detail that the initial setup tool can read the Anaconda configuration
file seemed like relevant background information when I was writing this
proposal, but since the plan is to not do that, it really does not need
to be described here.
Since that talks about something that will not happen yet, maybe move
it to some "discussion" section?
I'll just remove it from the page, since it does not describe the
current plan.
Also, please consider reworking the text to have in each section
first a short summary of what the decision is, and then the
justification
below. This text is long and it's hard to "scan".
I've shortened the text in some of the sections, and reversed the flow
of a couple others to present the proposal first, followed by
justification. Hope that makes it easier to skim.
Another possibility is to teach anaconda to use hostnamectl/hostnamed
to set the hostname. This would make things more consistent... We could
expose the code to canonicalize the pretty name as an api or command
line interface so that anaconda could show the pretty and canonicalized
names interactively.
That would be nice to do.
However, I don't think we would want to display the network setup page
even if it was adapted to use hostnamectl, since network configuration
belongs in g-i-s instead, and since it's weird to have a network
configuration page that allows setting only the computer's hostname. (It
allows configuring more than that in netinstall mode, but we're not
talking about netinstall mode.) Now, if the page were renamed to
"Computer Name" or something like that, then I think it would be fine.
Michael
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
