Comment # 16 on bug 1218158 from Stefan Hundhammer

We discussed in the team if we can continue supporting yast-nfs-server and
yast-nfs-client, and how useful those modules still are in this day and age.
There were arguments in favor and against it, but so far, we'd like to keep it.

But a full usr-merge migration just because of that idmapd.conf will not be
possible anytime soon; our focus is Agama, and there are hard milestones and
pending features for it.

So, a compromise could be to just drop support for the whole imapd thing.

In all the years that I have been working with Linux (since the late 1990s) and
Unix (HP-UX, SunOS, Solaris) from the late 1980s I have never seen any
environment where that ID mapping was actually used; in every instance user
accounts and their IDs were centrally managed (NIS / YP or IMAP or even
manually copied config files). Using idmapd IMHO is a fringe case within an
obsolescent (not completely obsolete) technology like NFS; it's a crude
workaround to a problem that shouldn't even exist in the first place in a sane
IT environment.

So, I propose to drop the part about imapd and its config file(s) from both of
those yast-nfs-{server,client} modules to extend their useful lifetime for
another few years; that should consume considerably less development resources
on the YaST side.