FS#46847 - UID and GID reservation for AUR packages
Attached to Project:
Arch Linux
Opened by Gordian Edenhofer (Edenhofer) - Friday, 23 October 2015, 20:31 GMT
Last edited by Gaetan Bisson (vesath) - Saturday, 31 October 2015, 05:50 GMT
Opened by Gordian Edenhofer (Edenhofer) - Friday, 23 October 2015, 20:31 GMT
Last edited by Gaetan Bisson (vesath) - Saturday, 31 October 2015, 05:50 GMT
|
Details
I would like to request UID and GID 64030 to be reserved in
the ID table of the ArchWiki [1] for an AUR package called
slurm-llnl [2]. Slurm is a very powerful job scheduler, used
on many supercomputers. On debian based hosts 64030 is the
preferred slurm-user id and group-id. To improve usability I
would recommend using the same UID and GID on arch. A short
discussion [3] about whether or whether not AUR packages may
be included in the ID table concluded in the advice by Alad
to open a bug.
I firmly believe that despite the fact that those PKGBUILDs are not written by Arch devs, the table should still mention at least some standard ID for devs not to use again. E.g. it would be usefull to know for a dev not to pick 64030 again because it is used by other distros (and the AUR package) for the slurm daemon, hence a entry in the table would definetly make sense. [1] https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database [2] https://aur.archlinux.org/packages/slurm-llnl/ [3] https://wiki.archlinux.org/index.php/Talk:DeveloperWiki:UID_/_GID_Database |
This task depends upon
Closed by Gaetan Bisson (vesath)
Saturday, 31 October 2015, 05:50 GMT
Reason for closing: Won't implement
Saturday, 31 October 2015, 05:50 GMT
Reason for closing: Won't implement
Comment by Gaetan Bisson (vesath) -
Saturday, 31 October 2015, 05:49 GMT
Many official packages happily use dynamic UID/GID assignment.
This is also the preferred way for AUR packages since, obviously,
coordinating unsupported PKGBUILDs would be a mess. Besides, you
give no reason why your package deserves a statically assigned
UID/GID, just that it would "improve usability" which to me seems
like just a buzzword you put there. Finally, 64030 falls outside
the static range as you can see in /etc/login.defs .