Yes! This is one more tread about the infamous -=systemD-VS-systemV=- flamewar. Ladies and Gentlemens choose your weapons !

[FredericGuilbault]

Nah, seriously :p ,

As part of #46 I tried to package both systemD and systemV file, but The lintian complain about it :

https://lintian.debian.org/tags/omitted-systemd-service-for-init.d-script.html

Astonishingly this is not a warning but an error. So likely the package will be rejected by launchpad.

Basically it's suggesting to drop the .init file as systemd will manage any call made to systemV as part of their compatibility/take-over effort... But if I don't package the .service file the lintian is ok with this solution. So what it really hates is having both packaged. Therefor a decision have to be made.

[stripydog]

We know that there are issues with systemd scheduling init scripts in compatibility mode: there have been multiple reports of problems with kplex so not packaging the unit file doesn't seem to be an option. Don't know if this is a stupid suggestion but what about putting the init file in /usr/share/kplex, potentially in conjunction with a post install script which copies the init script to /etc/init.d if it detects that systemd isn't running and a pre-remove script which removes it? Fallback would be a manual process. Of course to run on a wheezy-based raspbian you'd probably want to compile on a wheezy based raspbian and is there an issue with the appropriate build tools being available there?

[FredericGuilbault]

After research, looks like dh already have a tool to automaticaly manage service files dh_systemd_enable

In this doc they say:

When you are installing a systemd service file alongside of your SysV init script, you should name it correspondingly. E.g. for /etc/init.d/apache2 the corresponding service file should be named /lib/systemd/system/apache2.service. This way, systemd will automatically prefer the native service file over the SysV init script and use that to start the service.
[...]
If your service file is not provided by upstream and you ship it as part of your debian package, name it debian/$pkg.service and dh_installinit will install it to the correct location.

SRC:https://wiki.debian.org/Teams/pkg-systemd/Packaging

So that set good practices targets that run systemD IMO. But im still confused about what happend if the target run sysV and I don't find anything. I will need to test it.

[FredericGuilbault]

Of course to run on a wheezy-based raspbian you'd probably want to compile on a wheezy based raspbian and is there an issue with the appropriate build tools being available there?

So far I have build package for distribution throu launchpad who manage to build a package for each architecture and ubuntu version you request. They manage deps and everything. you give them your source code and they build all the packages.

For cross architecture local build I use qemu (in fact proot ) But I personally only need it for Buster based distro so far. (debian buster, raspios buster, raspbian buster and armbian buster. )

On the other hand, kplex don't have package dependency so AFAIK the distribution used does not affect affect the binary much ??

[stripydog]

On the other hand, kplex don't have package dependency so AFAIK the distribution used does not affect affect the binary much i think.

No package dependency but that doesn't mean there isn't a dependency on the package management tools or libc/base packages. I have a pi 1 model B running a wheezy based raspbian I was using to build kplex on ("lowest common denominator") so I can test if you can point me at a deb.

[FredericGuilbault]

After testing, The use of the internal debian helper functions allow to copy both .init and .service files. On the target OS. For now. To make it simple, I disabled the auto start of both services. Leaving the user the initiative to enable/start the one he/she want.

While doing this I realized that. kplex.service should not be started before someone edit the /etc/kplex.conf file anyway. The result of trying start the service without the config file set was. systemd[241278]: kplex.service: Failed at step EXEC spawning /usr/bin/kplex -p /var/run/kplex.pid -o mode=background: No such file or directory Am I getting this right or this error came from something else ?

[FredericGuilbault]

Im bumping this tread.... Sorry

In the context of a fresh install . Does kplex.service should wait for someone to edit the /etc/kplex.conf before being started. or it can be started on installation without previous user config ?

[stripydog]

Sorry for the late reply. Been super busy with work and not checked this email account for a while. The /etc/kplex.conf is an "example" rather than intended as a basic config. Moreover everything commented out so kplex would fail to start with "no inputs". So yes, the intention was have the user set up running as a service iff they wanted it started on boot. I could be convinced otherwise. What do you think?

…

On Sat, Jan 16, 2021 at 9:07 PM Frederic Guilbault ***@***.***> wrote: Im bumping this tread.... Sorry In the context of a fresh install . Does kplex.service should wait for someone to edit the /etc/kplex.conf before being started. or it can be started on installation without previous user config ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#50 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQCTHRNWJRNGVXQGXQSRPTS2H5ZZANCNFSM4UT67YCA> .

[FredericGuilbault]

I also see it that way, I just wanted to be sure.

As long as it requires manual configuration, there is no purpose into running it. It will just confuse users.

__
So that's all for my questions. The pull request I have made is ready for review now. And I'm fully available to make modifications if necessary.