Upgrading RPMs (in this case, XFree86-xfs) may cause their UID/GID's to change unnecessarily. This might be caused by user IDs 100<x<500. This seems to happen because the user is first deleted w/ userdel and then added w/ adduser. I was wondering if RPM uninstall scripts could first check which uid/gid the user (e.g. xfs) is using, and when adding him try to use his old UID:GID first (and if that doesn't work, perhaps try to use whichever the algorithm decides). This matter mainly concerns the people who use Linux in a heterogenous Unix environment w/ shared user UID/GIDs. Tweaking the RedHat's system UID/GID's down to like 80-100 will be much more difficult since RPM upgrades don't "honor" these changes at all. I think there was an open letter or something about RedHat Linux using GIDs and UIDs >100 for system accounts. Using something a range like 50-80 would seem pretty much safer to me when trying to get people to use RHL in aforementioned heterogenous Unix environments.
This should not happen. The xfs user is created before the package gets installed, and rpm uses only symbolic names ofr files ownership. What problem did you exactly encounter and how can we reproduce it?
There seems to be a misconception here on my part. The UID/GID change wasn't actually caused by useradd/userdel scripts in XFree86-xfs RPM. What really happened: 1) XFree87-xfs was installed as usual, it gets UID/GID's like 300-400 (that range seems pretty standard for RH). 2) The box is included in a site-wide password/user account synchronizing scheme, and all UID/GID's above 100 are removed from passwd files. To avoid the problem, I should have moved xfs account to UID/GID below 100. 3) The RPM is upgraded and a new xfs account is created (with non-previous UID/GID's, naturally). Still my (and other people's) concern about using UID/GID's 100<x<500 for system configurations is IMO a valid one.