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

Support multiple versions of systemd and use project level setting to determine the version. #98

Open
SJrX opened this issue Jul 21, 2020 · 4 comments

Comments

@SJrX
Copy link
Owner

SJrX commented Jul 21, 2020

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)

@SJrX
Copy link
Owner Author

SJrX commented Jul 21, 2020

@stephenreay just how old a version are you using?

@stephenreay
Copy link

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!

@SJrX
Copy link
Owner Author

SJrX commented Jul 21, 2020

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.

Coolio that should be doable.

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.

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.

If I can assist with checking documentation to identify changes between versions, then please let me know!

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?

@stephenreay
Copy link

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.

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