Bug#796603: closed by Anton Zinoviev <zinoviev@debian.org> (Bug#796603: fixed in console-setup 1.138)
On 6 March 2016 at 19:29, Anton Zinoviev <anton@lml.bas.bg> 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
>> package.
>
> I agree in 100% with this.
Would you be OK, until further development comes along, to use a
wrapper unit like this:
[Unit]
Description=Set the console keyboard layout
DefaultDependencies=no
Before=local-fs-pre.target
Wants=local-fs-pre.target
ConditionPathExists=/bin/setupcon
[Service]
Type=oneshot
ExecStart=/etc/init.d/keyboard-setup.sh start
RemainAfterExit=yes
[Install]
WantedBy=sysinit.target
And mutatis mutandis for console-setup.sh? While not being the optimal
setup, it works, and avoids reliance on the debian-specific runlevel S
support.
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.
--
Saludos,
Felipe Sateler
Reply to: