Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
replace deprecated usage of PermissionsStartOnly (part 2) #56265
Motivation for this change
Feb 24, 2019
Feb 24, 2019
I'm guessing quite a few of these modules don't have tests.
In rare situations there could be implications in changing from a mkdir+chmod in the preStart script (which runs every time the service starts) to tmpfiles (which doesn't run every time the service starts, from what I read).
Given that I don't know or use many of these modules I'd say run a test when it exists as a first pass, but also ping maintainers, then we can cherry pick individual module commits one by one. Given the timeline I think that should work out.
For now I plan to hammer away at the brainless modules which are low hanging fruit, and then progressively work my way up to modules which require more thought and understanding of the program/service. That being said, if anyone wants to start pinging maintainers so individual commits can be cherry picked feel free.
Update as of 2019-04-13: Thanks to everyone for their review and feedback. The first batch of changes which have either been reviewed or have a passing NixOS test are now going to be merged into master and then removed from this PR.
Quick Summary: PermissionsStartOnly is deprecated and a module that you are listed as a maintainer for uses it. I have patched the module you maintain to not use PermissionsStartOnly anymore, but I would like a module maintainer (ie. you) to review the changes and sign off on it.
More details: #53852
Please review the list below for your name and review the changes to your module(s). I haven't ran tests yet, so if you want to run a test and confirm everything is working, that all the changes makes sense, and there won't be any problems from my changes, that would be appreciated.
If you have the ability to merge please go ahead and cherry pick the commit relevant to your module(s) if everything checks out and you're happy with the changes and then check off your module. If you do not have commit access please leave a comment stating that you accept the changes and are OK for them to be merged as is.
If there are problems with the changes it would be great if you could provide a fix, or at least explain what the issue(s) are.
Thank you for your time and effort.
Note: If a module is checked that means no further action is required (because the module has already been merged, deprecated, taken care of by someone else, etc...)
not reviewed, but covered by tests
not reviewed, not covered
module to be deprecated
modules which I haven't written code for (yet?)
@Mic92 This is split into smaller. Normally I agree that too many changes are hard to digest, but in this case I thought everything is similar so I would keep in fewer PRs with 1 commit per change unless explicitly asked. Does anyone else request more PRs to split this up?