Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions on non-systemd support #158

Open
Dariqq opened this issue Mar 1, 2024 · 2 comments
Open

Questions on non-systemd support #158

Dariqq opened this issue Mar 1, 2024 · 2 comments

Comments

@Dariqq
Copy link

Dariqq commented Mar 1, 2024

Hi,

It looks like the comment on systemd was removed from the README in 4230bde. Have there been any changes other than what is said in #80?

Also could some of the explanations for why systemd is used from the other issue be added to the README (mainly hidraw device changing after suspend) such that they are easier to find?

Additionally would it be possible to document the suboptimal workaround of building with "-Dservice_manager=" and the wrapper script/the equivalent openrc service, which from what I have read should work but requires manual restarting to refind the hidraw device (please correct me if i am wrong with this)?
Maybe these files could also be added as service_manager options (but clearly indicating that the experience with them is inferior) to have at least a very basic support..

Thanks.

@StollD
Copy link
Member

StollD commented Mar 1, 2024

It looks like the comment on systemd was removed from the README in 4230bde. Have there been any changes other than what is said in #80?

No, i removed it because it isn't really relevant to the project as whole, and we only package it for systemd distributions.

However ...

Also could some of the explanations for why systemd is used from the other issue be added to the README (mainly hidraw device changing after suspend) such that they are easier to find?

... I agree that this is useful information, so I am going to add that back in it's own section.

Additionally would it be possible to document the suboptimal workaround of building with "-Dservice_manager="

That isn't a workaround, thats just how meson works. The option accepts a list of entires, what you posted is just the empty list. I designed it like that, so that we could at some point build a Debian or Arch package that supports multiple service managers.

Right now I agree that it is pretty useless, but changing it to e.g. a boolean would break downstreams and idk if that's worth it.

the equivalent openrc service, which from what I have read should work but requires manual restarting to refind the hidraw device (please correct me if i am wrong with this)?

Yes, it may break after resuming from suspend.

Maybe these files could also be added as service_manager options (but clearly indicating that the experience with them is inferior) to have at least a very basic support..

I don't want to ship services that don't work correctly and give the impression that they are supported.

@Dariqq
Copy link
Author

Dariqq commented Mar 1, 2024

thanks for the answers.

With workaround I meant just running a service that runs "iptsd $(iptsd-find-hidraw)" ignoring the device changing problem.

I don't want to ship services that don't work correctly and give the impression that they are supported.

Completely understandable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants