Bug#796603: closed by Anton Zinoviev <firstname.lastname@example.org> (Bug#796603: fixed in console-setup 1.138)
On 6 March 2016 at 19:29, Anton Zinoviev <email@example.com> wrote:
> Thank you for the useful explanations in your message!
Glad they are useful :)
> On Sun, Mar 06, 2016 at 02:51:34PM -0300, Felipe Sateler wrote:
>> I meant the logic to determine if setupcon or the cached scripts should be
>> run. If in the future that part is changed (eg, the names are changed, or
>> more scripts are generated), there is no guarantee the change will reach
>> users, since they may have modified the init script.
> I see... Yes, you are correct about this.
>> However, this is not exactly the same: if the cached script fails, then
>> setupcon would not be run.
> I was just pondering on the different options I had. One of them was
> to change the cached script so that it runs setupcon when necessary.
Yet another one would be to have setupcon itself detect the existence
of the cached scripts.
>> Also, I would advise against having different logic in the systemd services
>> than in the init scripts: the maintenance burden is higher, and requires a
>> higher initial understanding from people not already familiar with the
> I agree in 100% with this.
Would you be OK, until further development comes along, to use a
wrapper unit like this:
Description=Set the console keyboard layout
And mutatis mutandis for console-setup.sh? While not being the optimal
setup, it works, and avoids reliance on the debian-specific runlevel S
I plan to do a NMU fixing this bug via a unit like the above, please
tell me if you want to address this in some other way.