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

[Michael Schutte]

On Mon, Feb 10, 2014 at 02:54:45PM +0200, Anton Zinoviev wrote:
> 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 see, thanks for elaborating.  This does sound appealing, but what
should happen in an upgrade if the package into which we move the
conffiles (IMHO this should be console-setup) is not installed on a
particular system?  Unless we add dependencies from console-common and
kbd (this one would be circular) to console-setup, or move all conffiles
to kbd instead (which is the one package that is sure to be present), we
are stuck with these dangling conffiles anyway.

What do you think of the plan that I've already hinted at: Drop
everything in /etc from the console-common and kbd binary packages.
dpkg will of course leave them behind on upgrade, and they are only
actively removed through maintainer scripts if they are all unmodified.
Systems which have been relying on the legacy features of kbd and
console-common can thereby continue to do so, whereas new installs are
unencumbered by the historical clutter.  This also means that we provide
less configuration options on new installs, but I assume that the lost
options are in fact very rarely used, and we can gradually reintroduce
(some of) them to /etc/init.d/console-setup and/or setupcon, configured
through /etc/default/{keyboard,console-setup}.

> > 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.

I like this idea.  The /etc/default/{keyboard,console-setup} variables
should have precedence in such a scheme, because even now, console-setup
overrides the configuration from console-common and kbd.

> 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?

/etc/console/boottime.kmap.gz is the only other one I can think of at
the moment.

Cheers,
Michael