[ubuntu-studio-devel] Shouldn't rtirq become a systemd unit?

[Ralf Mardorf]

On Thu, 06 Aug 2015 14:19:41 +0200, Kaj Ailomaa wrote:
>On Thu, Aug 6, 2015, at 12:59 PM, Ralf Mardorf wrote:
>> Hi,
>> 
>> below is how rtirq currently looks like for the systemd based Wily
>> and below that how a systemd solution could look like [1].
>> It shows the rtirq service file. Btw. moving rtirq to bin comes with
>> a convenient side effect, a user simply can run "rtirq status" by
>> command line, without a path or service wrapper.
>> 
>> Is there a reason that rtirq for Ubuntu Studio still is an init file
>> for sysvinit or upstart usage and the used init process is ignored?
>> 
>rtirq, like most of the packages we provide is packaged in Debian. We
>do very little packaging work, but when we do, it is preferred to do
>it in Debian.
>
>If you like, you can ask the Debian Multimedia team about this. It is
>they who package most of the multimedia packages we provide.

Are you aware that the "service" wrapper changed its behaviour?
If you run

$ service rtirq status

you don't get the status information of RT priorities anymore, instead
you get systemd unit status information. That's grotesque,
compatibility to the original "service" wrapper is lost, just to
provide what

$ systemctl status rtirq.service

now does anyway.

You can still run

$ /etc/init.d/rtirq status

but compatibility to the original "service" wrapper is lost, while at
the same time there's no compatibility to a Linux install with a clean
systemd.

To funny, the Claws package maintainer's excuse not to update the
claws-mail package for Ubuntu was also "Debian". I didn't send this
request, I build the claws package on my own and helped a user to do
the same.

No, I won't ask Debian to get things done. Am I using Debian? The init
system install from a server ISO that is smaller than 2 GiB already is
a mess. Isn't this of value for the Ubuntu Studio developer list?

It's also very risky that while the package rtirq-init didn't provide
rtirq.service, it was generated and the unit was enabled. That's a
behaviour I expect from restricted operating systems only.

I already read "man systemd-sysv-generator" ;) perhaps it's worth to
add

alias microsoft-PITA-simulator='/lib/systemd/system-generators/systemd-sysv-generator'

Why not integrate scripts directly by the package for sane systemd usage?

This mess at best makes sense, if the user could chose between several
init systems and even then it would be questionable, if it would be the
best way to provide it. However, when providing systemd only, then the mess
is only a mess, is a mess, is a mess, that is good for absolutely nothing.
It's just risky and likely will cause issues again and again.

2 Cents,
Ralf