-
Notifications
You must be signed in to change notification settings - Fork 7
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
Support multiple versions of systemd and use project level setting to determine the version. #98
Comments
@stephenreay just how old a version are you using? |
The problem where I see it mostly at the moment is on Debian Stretch, which currently gets 241 from the backports repo or 232 without backports enabled. I realise its likely not possible to add the metadata for which version gained/lost/changed each property and it's possible values from the last decade, but realistically even if the data started now, that'd be worth it for future versions. If I can assist with checking documentation to identify changes between versions, then please let me know! |
Coolio that should be doable.
Actually that should be fairly straight forward, the main annoyance will be that systemd's documentation isn't perfect. On a few releases I've had to open bugs against them because some documentation is missing. Other than that the plugin currently checks out the source code and does some building to figure out what is supported where.
I guess the main question I have for you is lets say this feature is implemented, this would warn you when you try an option not supported by the project level setting. How would you find out what keys are supported by that version? |
So far, when I've found it isn't supported (the hard way) I'll generally then refer back to e.g systemd release notes to find references to that property, and see where it was added/changed. For the Debian-specific use case, the version-specific man pages work (https://manpages.debian.org/stretch-backports/systemd/systemd.unit.5.en.html), but other times I'll just jump straight to the man pages directly in the dev environment (i.e. a local vm) directly, as I probably had a shell open to test the unit file I was working on anyway. |
It'd be nice if this behaviour could be similar to the native language support behaviour.
i.e. you specify a project-level setting for the systemd version you're targeting, and the plugin will identify properties that are not supported yet, obsolete, etc. I've had more issues with online documentation showing a property (and no notes about introduction version) but then it turns out that version is too new for the distro/release $PROJECT is using.
Originally posted by @stephenreay in #68 (comment)
The text was updated successfully, but these errors were encountered: