You are not logged in.
I was attempting to install the terraria-server but couldn't because another service in the server already uses the GID 197
Here's the PKGBUILD in question
Is manually setting the GID a common practice?
Is this ok?
Can I just set it to whatever number as long as it is consistent or will I have trouble updating it in the future?
Should I rename the GID of the other service?
Should I flag it this AUR pkg?
I'm not sure how to proceed.
Offline
No clue about harcoding UID/GID in PKGBUILD, but 197 is a bad choice for an aur package.
Check https://wiki.archlinux.org/index.php/De … D_Database , 197 is used by rabbitmq from [community] .
I suggest to add a comment about this on terrarria-server aur page It should be named teraria-server-bin imo as it installs pre-compiled stuff ) .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
No clue about harcoding UID/GID in PKGBUILD, but 197 is a bad choice for an aur package.
Check https://wiki.archlinux.org/index.php/De … D_Database , 197 is used by rabbitmq from [community] .
I suggest to add a comment about this on terrarria-server aur page It should be named teraria-server-bin imo as it installs pre-compiled stuff ) .
Yes, RabbitMQ is the service in question. I'll guess I'll have to flag it.
Offline
Why do you want to hardcode a GID anyways? Groupadd will create a new gid that doesn't conflict with anything currently on the system. You can't create this group until the install script, but you could chown the relevant files to that group in the install script instead of trying to hardcode a numerical group value.
EDIT: see the following discussion on why my suggestion is probably not the right approach.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
The install script has a bug, I have posted a comment on the package site.
Why do you want to hardcode a GID anyways? Groupadd will create a new gid that doesn't conflict with anything currently on the system. You can't create this group until the install script, but you could chown the relevant files to that group in the install script instead of trying to hardcode a numerical group value.
In addition, please have a look at the groupadd manpage and /etc/login.defs. There are GID_MIN/MAX and SYS_GID_MIN/MAX variables:
#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN 1000
GID_MAX 60000
# System accounts
SYS_GID_MIN 500
SYS_GID_MAX 999
Offline
If you want packaged files or dirs to be owned by that group, then yes, hardcoding the GID is normal and necessary.
Offline
If you want packaged files or dirs to be owned by that group, then yes, hardcoding the GID is normal and necessary.
Would it be okay to add the group ID to this list, then? https://wiki.archlinux.org/index.php/De … D_Database
Offline
If you want packaged files or dirs to be owned by that group, then yes, hardcoding the GID is normal and necessary.
Scimmia, this makes sense to me for established/commonly used groups like those in the wiki link above. But in this case this is a group specifically for this software. It seems to be there is no reason that it needs to have a specific number for the GID: there is no reason the group needs to have the same numerical value on different systems. Based on this it would be safer and easier to create the group in the install script and chown the relevant files.
Is there something I'm missing that would favor using a specific number for this group and set this in the PKGBUILD?
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online
Awebb, unfortunately, that page is really only for packages in the official repos. AFAIK, there's not a central database for packages in the AUR, and that can cause problems like this.
Trilby, the main thing is that files and dirs should not be being chown'd in the post-install/upgrade scripts. Doing this can screw up custom configurations, which is why pacman doesn't automatically change ownership when the package differs from the filesystem. If a file or dir should be owned by a specific user or group, it should be set in the package function, which requires a static UID/GID.
Offline
Thanks, that makes sense.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Online