Bug#1108458: unblock: slurm-wlm/24.11.5-3
Hi Marc,
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.
Best regards,
--
Gennaro Oliva
Reply to: