On Wed, Jul 06, 2005 at 07:17:43PM -0700, Michael A. Peters wrote:
There is thus no conflict - no need to reserve an extra range of
for extras (or any other repository). As long as the package adds its
user as a system account or is already present from previous /etc/passwd
file - there are no conflicts, none. If the rpm doesn't add the user as
a system user - then there is a bug in the packaging.
let's say you have server-program-foo, and server-program-bar. On your first
install, server-program-foo got installed first and created user "serverfoo"
as uid 101, and server-program-bar created "serverbar" with uid 102. Now, on
the second install, for arcane RPM transaction ordering reasons,
server-program-bar gets installed first -- and gets stuff owned by new user
"serverbar" uid 101. Now, when you put your password file back, uid 101
reverts to "serverfoo", all of the files are owned by the wrong user. You
may not even notice it until something breaks, but it ain't right.
(And that's not even considering that you accidentally wiped out the new user
created by server-program-baz, which requires a separate user account in the
new version and you didn't notice before copying your passwd file on top of
the new one.)
I guess what I'm trying to say is I don't see a problem with
the way it
is currently done, nor do I see how a registry of uid/gid's solves
It solves the above problem, and *also* issues with backup, with networked
filesystems, and more.
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 78 degrees Fahrenheit.