Re: (newbie) Disruptive LIRC package update.
On 08/11/15 19:28, Dominique Dumont wrote:
> On Sunday 08 November 2015 15:19:30 Alec Leamas wrote:
>> Some tooling to build the new configuration from the old will indeed be
>> required. This is actually some work - it includes a complete lircd
>> command line parser with ~18 options. But it's certainly doable.
>
> Good to know
>
>> The real reason why I think some user intervention is if not necessary
>> at least desirable is the semantic gap between the old and new
>> configuration. In particular, the current config enables the 'lirc'
>> service which then starts up to four different server processes. The new
>> config is actually up to four different systemd services which need to
>> be handled separately by the user.
>
> If I rephrase, with the current setup, 'service lirc start' starts 4 daemon
> processes.
>
> Which means the user only has to type one command to start and stop all of
> them.
>
> With the new setup. the user will have to deal with 4 systemd services (one
> per daemon) and will have to run 4 systemctl commands to start or stop lirc.
>
> Is that correct ?
Yes. But "user only has to type one command to start and stop all of
them" is sort of misleading. The four services are actually three (my bad):
- lircd (always used)
- lircmd (seldom used to let the remote emulate a mouse)
- irexec (sometimes used to let a remote runn random system commands)
Each of these services requires specific setup. What the current lirc
script does is to look at the setup and then decides to start a service
or not. E. g., if the irexec.conf file exists and is "good" according to
some conditions AND the START_IREXEC configuration variable is not
false, then 'service lirc restart' starts irexec
Now, is this simple? Simpler than, if you want to configure irexec,
create the configuration file and run systemctl start irexec.service? I
don't see it that way.
And, not to forget, if I should stick to this convention there would be
a need of much more downstream documentation, since this is different
from upstream and all other distros which have packaged lirc beyond 0.9.0.
So, this is a change, yes. But in the long run, wouldn't we be better
off by sticking to upstream's way of doing it instead of running a
separate Debian race? Yes, I have both hats. But still...
Cheers!
--alec
Reply to: