Hi Jason,

>Still, I wonder if this could introduce support challenges for packages that
>incorrectly assume UIDs are 16 bits wide, since they traditionally were that
>way in UNIX,

I don't think that these 16 bit problems are common at all since all the
getuid() syscalls I've ever seen, even in traditional UNIXes, have "int" as
return value--and nowadays that's at least 32 bits; and also because UNIX
configuration is usually in text files, which would read and store the stuff
using "%d".  That said, it's possible that it could happen in some seriously
strange configurations (I doubt it).

> and since other Linux distros still seem to prefer small UIDs in
> their packaging. By comparison, my earlier idea of declaring static UIDs/GIDs
> in the operating-system is decidedly less elegant, but it avoids this particular
> risk. 

If we did something like that, I would prefer for guix services to just specify
a fixed UID/GID for each of the entries in gnu/services/*.scm.  We can even
reuse existing system uids and gids that have been statically allocated
already by FreeBSD and Debian and be even uid/gid compatible to those.

For example, change Guix to do (similarly for all Guix services using user
accounts):

diff --git a/gnu/services/monitoring.scm b/gnu/services/monitoring.scm
index 5123a8c441..45d3f4ad17 100644
--- a/gnu/services/monitoring.scm
+++ b/gnu/services/monitoring.scm
@@ -71,6 +71,7 @@
 
 (define %darkstat-accounts
   (list (user-account
+         (uid 4711)
          (name "darkstat")
          (group "darkstat")
          (system? #t)
@@ -78,6 +79,7 @@
          (home-directory "/var/lib/darkstat")
          (shell (file-append shadow "/sbin/nologin")))
         (user-group
+         (id 4711)
          (name "darkstat")
          (system? #t))))

And other constants for other user names.

Or use hashes.  Whichever.  The point is that the ids are deterministic--not
necessarily that we need to use hashes.  The advantage of using a hash is that
we don't need a central registry and this problem will be out of our life once
and for all.

Anyway, as a workaround for your immediate problem, I suggest to preserve
/etc/passwd, /etc/group and /etc/shadow--present entries in those will be
preferred by Guix to even its own configuration.  (I'm not sure whether that's
currently easy to do with guix system container, however)