change of names of configuration files

Bill Nottingham notting at redhat.com
Fri Oct 26 03:50:54 UTC 2012


Adam Williamson (awilliam at redhat.com) said: 
> anaconda has been writing to vconsole.conf for some time now - at least
> Oct 4th:
> 
> commit 4b98eab34f310c2704ec24b417bdf919c413fa1d
> Author: Vratislav Podzimek <vpodzime at redhat.com>
> Date:   Thu Oct 4 12:37:24 2012 +0200
> 
>     Work with VConsole keymap and X layouts separately
> 
> ...
> 
>     Resolves: rhbz#853877
>     Resolves: rhbz#856362
>     Resolves: rhbz#859867
> 
> In fact we've always had problems with X and console keymaps; there's a
> longstanding bug about the encrypted partition case:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=743281
> 
> It's a rather complex area. I don't have a 100% grasp on it, but I
> _think_ F18 actually behaves rather _better_ than previous releases at
> this point.
> 
> I think Marcela's mail is slightly misleading. The 'new' locations for
> these files have existed and systemd has been using them for some time.
> The commit Marcela linked provided RPM scripts that automatically
> migrate to the new locations; it doesn't actually introduce the new
> locations.


Right. Since F16 when systemd took over the basic startup of the system,
it's had to set things like:
- keymap
- font
- locale
- hostname
etc.

It's always had the policy where it reads a heirarchy of locations
for these settings:
1. the kernel commandline
2. a cross-distro default location
3. a distro specific location (for example, /etc/sysconfig/i18n on
  Fedora-alike, /etc/sysconfig/language on SuSe, /etc/rc.conf on Arch...
  it's a large pile of #ifdefs, and it's why there is a cross-distro
  default location suggested)

In each case, the later location overrides the former. (Except for
hostname ... I'll go file that one.)

Options would be:

1. ignore the cross-distro locations, never use them, patch them
out where they occur
2. ignore the distro-specific locations, never use them, patch them
out where they occur (hooray, flag day!)
3. Accept both. Deal with confusion if people have both files present.
4. Attempt to patch everything to only support one variant, but allow
for the other where available.

Fedora's done #3, and has done so since F-16. We get the occasional bug from
this, usually when someone's used one tool that writes a config to one file
location, and another that assumes another. 

That's not a good long term solution, so discussion was to take what format
anaconda is writing for new installs, and convert old installs to that
format, so that upgraded systems match (all the while while the old location
still works for those that modify their configs by hand, or with old tools.)

Of course, in checking the code, anaconda for the moment is writing *both*
files with identical data.

Bill


More information about the devel mailing list