I'm not well versed in this systemd stuff, but don't you now have two competing methods? I mean, if both adduser and systemd-sysusers are
installed and configured, what will happen? And I guess adduser can be
not yet configured if systemd-sysusers is already configured, will the
logic in your preinst then do the right thing?
I'm not well versed in this systemd stuff, but don't you now have two competing methods? I mean, if both adduser and systemd-sysusers are
installed and configured, what will happen? And I guess adduser can be not yet configured if systemd-sysusers is already configured, will the logic in your preinst then do the right thing?
In short, yes, it works* in any combination of the two prerequisites.
What is expected is that both `adduser` and `systemd-sysusers` only kick in if the UID/GID doesn't yet exists, so there is no double creation of the
same IDs. I've tested with all combinations of adduser is preinstalled, systemd-sysuser is preinstalled, both, neither; all finish installation
fine.
On Tue, Jul 08, 2025 at 10:19:59AM +0200, G�bor N�meth wrote:
In short, yes, it works* in any combination of the two prerequisites.
What is expected is that both `adduser` and `systemd-sysusers` only kick in if the UID/GID doesn't yet exists, so there is no double creation of the same IDs. I've tested with all combinations of adduser is preinstalled, systemd-sysuser is preinstalled, both, neither; all finish installation fine.
Pardon me for jumping in. I am the adduser maintainer. slurm-wlm is
actually one of a low one digit number of packages that have adduser in
their pre inst. May I ask for the reason you have to create your users
in pre-inst and therefore need a pre-depends on adduser?
Would it be possible that you don't need that and just create your users
in postinst and just need a regular dependency on adduser?
Using one method or the other seems to be unusual and sounds like asking
for trouble intentionally. I would like to know what led you to this
solution
Pardon me for jumping in. I am the adduser maintainer. slurm-wlm is actually one of a low one digit number of packages that have adduser in their pre inst. May I ask for the reason you have to create your users
in pre-inst and therefore need a pre-depends on adduser?
Would it be possible that you don't need that and just create your users
in postinst and just need a regular dependency on adduser?
Using one method or the other seems to be unusual and sounds like asking for trouble intentionally. I would like to know what led you to this solution
Pardon me for jumping in. I am the adduser maintainer. slurm-wlm is
actually one of a low one digit number of packages that have adduser in
their pre inst. May I ask for the reason you have to create your users
in pre-inst and therefore need a pre-depends on adduser?
The slurm user is not actually used in the package where it is created,
but only in three other packages that depend on it. It is included there
to simplify the process of removing one of them while keeping the other.
It was placed in the preinst script out of an abundance of caution.
Would it be possible that you don't need that and just create your users >> > in postinst and just need a regular dependency on adduser?
I wasn't aware that having adduser as a Pre-Depends could be such a >significant issue. I created a new version of the packagte with adduser
in postinst that looks fine in my testing environment.
Using one method or the other seems to be unusual and sounds like asking >> > for trouble intentionally. I would like to know what led you to this
solution
Regarding the coexistence of the two methods for adding the user, I
accepted the merge request as submitted because I assumed there might be >systems not using systemd.
The slurm user is not actually used in the package where it is created,
but only in three other packages that depend on it. It is included there
to simplify the process of removing one of them while keeping the other.
It was placed in the preinst script out of an abundance of caution.
I would recommend to have the adduser call (it SHOULD really just be one single line) in the postinst of every pakage needing the user. If you need scaffolding around adduser in postinst, it is likly that I would consider that a bug in adduser and act appropriately (but we're frozen at the
moment).
I would also recommend to not remove your user on package deinstallation.
Thank you. It is usually fine to have adduser in preinst but then your package must be prepared to be able to run with the adduser from oldstable during upgrade. This is kind of a challenge to test, and that's the reason I recommend not to do this without having a VERY good reason.
Regarding the coexistence of the two methods for adding the user, I accepted the merge request as submitted because I assumed there might be systems not using systemd.
I haven't really thought about whether this might make sense, but just be aware that this is an unusual pattern that has been seldomly tried.
On Tue, Jul 15, 2025 at 10:11:22AM +0200, Marc Haber wrote:
The slurm user is not actually used in the package where it is created,
but only in three other packages that depend on it. It is included there >> > to simplify the process of removing one of them while keeping the other. >> > It was placed in the preinst script out of an abundance of caution.
I would recommend to have the adduser call (it SHOULD really just be one
single line) in the postinst of every pakage needing the user. If you need >> scaffolding around adduser in postinst, it is likly that I would consider
that a bug in adduser and act appropriately (but we're frozen at the
moment).
The only check I perform before calling adduser is verifying whether the
user already exists. This allows the flexibility to use Slurm with a >different UID in case our fixed UID conflicts with the site's policy.
I would also recommend to not remove your user on package deinstallation.
This would greatly simplify things. Is this a common practice?
Thank you. It is usually fine to have adduser in preinst but then your
package must be prepared to be able to run with the adduser from oldstable >> during upgrade. This is kind of a challenge to test, and that's the reason I >> recommend not to do this without having a VERY good reason.
I haven’t noticed any changes affecting the command-line options I use,
and my invocation of adduser has remained more or less the same for
years. Am I underestimating any potential pitfalls?
Regarding the coexistence of the two methods for adding the user, I
accepted the merge request as submitted because I assumed there might be >> > systems not using systemd.
I haven't really thought about whether this might make sense, but just be
aware that this is an unusual pattern that has been seldomly tried.
Thanks for the advice and for all your comments in general.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 42:02:27 |
| Calls: | 12,109 |
| Files: | 15,006 |
| Messages: | 6,518,416 |