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 -- ubuntu-studio-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
