-
Notifications
You must be signed in to change notification settings - Fork 161
fix(all): revert sysusers #1210
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
Conversation
|
Thanks! /cc @vvoland FYI We'll probably be rebuilding the packages without the systemd-sysusers patch, and deploy new packages, keeping the systemd-sysusers change for a next release |
This reverts commit 8c5e99f. Signed-off-by: Robert Sturla <robertsturla@outlook.com>
5789968 to
a76bedc
Compare
|
@thaJeztah I'm very sorry for the inconvenience here! |
|
Yes; that's what we want to do. looks like it's the last commit in the branch, so we can build using the commit before that (but we could do an explicit revert PR as well) |
|
Ok - please do whatever you can to fix the immediate issue of the broken release, and I'll figure out the proper fix to the issue. I'm kinda strongly for reverting at least the Debian scripts since I'm completely in the dark on how it works, and it seems there's quite a bit of tech debt in this area. Again, I'm very sorry for this! |
|
No worries! We're also looking why our deploy pipeline didn't flag it; likely because it may have verified an upgrade on the same machine, so the user/group to have been there. |
|
I'm thinking the "proper" fix (i.e. to keep using sysusers across the board) would be to do something like: This uses a built-in macro for RPMs and adds back the postinstall command to the deb, which both invokes the sysusers file. Though in the other thread somebody said sysusers isn't used in Ubuntu and Debian, which I wasn't aware of. How do you want to play this? |
|
Reverted for now, let's open a new PR to discuss the new solution. |
- What I did
Reverted the systemd-sysusers change.
- Description for the changelog