[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

Description=Set the console keyboard layout

ExecStart=/etc/init.d/keyboard-setup.sh start


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.


Felipe Sateler

Reply to: