On 6 March 2016 at 19:29, Anton Zinoviev <an...@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
