On Thu, Jul 17, 2025 at 07:53:02AM +0200, Gennaro Oliva wrote:
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.
Please try what your adduser call does when the user already exists or
when it exists with a different UID. Please consider sending the
typescript of that session to me, maybe there is some behavior that
aduser can improve in forky.
I would also recommend to not remove your user on package deinstallation.
This would greatly simplify things. Is this a common practice?
It is a rather common practice. Justification is that you cannot make
sure on deletion that the local admin didn't give any files to your user
that your package doesn't know about and we should not leave "unowned"
files laying around. Sadly, policy has not adapted to that in over a
decade.
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?
I tink so. Frankly, I don't know. I didn't have that usecase on my radar
during the last two cycles.
> 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.
You're welcome.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
