Unfortunately, we have some groups containing enough users to exceed
NIS's 1024-byte limit on the size of a map entry. (glibc no longer
enforces this limit, but we have other NIS implementations on our
network that do.) There is a workaround for this, documented in the
NIS HOWTO <http://tldp.org/HOWTO/NIS-HOWTO/maps.html#AEN548>:

However, this description does not quite match the current behaviour of
the nis package. As the data are fed to makedbm, each line replaces any
matching entry already in the database, so it is in fact the _last_ line
with a given GID that goes into the group.bygid map. Meanwhile, on the
NIS master, lookups try /etc/group first, and find a GID by simple
linear scan, stopping at the first match (as above). Therefore, if we
want the "correct" group names in the NIS database, we must tolerate
incorrect names on the NIS master.

For the generated map to be consistent with file-based lookup, it must
instead take the first entry for each GID. There are two fairly simple
ways this could be achieved:

* makedbm could insert entries into the database in no-replace mode, and
  simply ignore that particular error. That way, subsequent lines with
  the same GID would have no effect. (This may, however, have unwanted
  consequences for other maps. I have not checked.)

* Alternatively, for group.bygid only, reverse the data before passing
  to makedbm, e.g. by piping through tac. For any given GID, the first
  entry in /etc/group is now the last one received by makedbm.

Obviously, either of the above fixes would create some problems for
package upgrades. Just going ahead and changing the behaviour, without
reordering entries in /etc/group, could break existing installations.