[Pkg-kbd-devel] Bug#734164: console-data: should conflict with console-setup

[Anton Zinoviev]

On Sun, Feb 09, 2014 at 12:12:31PM +0100, Michael Schutte wrote:
> 
> I'm not sure if I understand this point.  Would you like to keep these
> old configuration files?

Not at all.  It's just that the idea of leaving behind the modified 
legacy conffiles unowned never occurred to me.

Since there is some functionality which is supported by the legacy 
scripts but currently unsupported by setupcon, it seemed to me that we 
have to support (for a while) this functionality outside of setupcon.  
In case we decide not to leave behind the modified legacy scripts the 
only option seems to be to keep the legacy scripts (and conffiles) in 
one place.  The reason I proposed to start with this change is because I 
think it will be easier for us this way.

> I do not like the idea of having an /etc/kbd/config owned by
> console-setup, for example, when the same options can and should be
> changed through /etc/default/console-setup.

/etc/kbd/config is not a problem.

Currently we have /etc/default/keyboard and /etc/default/console-setup 
but the scripts of console-setup make no difference between these two 
files.  For example, if one prefers, he can move the contents of 
/etc/default/console-setup to /etc/default/keyboard and everything will 
be OK.

Now, as far as I can tell there are no variable conflicts between the 
variables of /etc/kbd/config and /etc/default/{console-setup,keyboard}. 
So while it won't be possible to add all required functionality to 
setupcon, we can get rid of /etc/kbd/config right now -- we only have to 
make the legacy scripts in /etc/init.d/ source not only /etc/kbd/config 
but also /etc/default/console-setup.

Regarding /etc/init.d/{kbd,keymap.sh}, one option is to leave them as 
they currently are (but both owned by one package).  Another option is 
to merge them with /etc/init.d/{keyboard-setup,console-setup}.  While 
I'd like to keep setupcon clean, I don't mind adding to these init.d 
scripts as many legacy stuff as necessary.

Are there some other legacy conffiles we have to consider?

Anton Zinoviev