Few points:
- implementing this would reduce the workload as several of these netkit tools are orphaned
- inetutils doesn't contain a replacement for bsd-finger (there might be others) so we'll need to keep it in the repo. I don't even know what it does/ if it's useful.
- netkit-telnet is in core so inetutils should be added to core.
- it needs a patch to build:
+Index: inetutils-1.5.dfsg.1/libicmp/icmp_timestamp.c
+===================================================================
+--- inetutils-1.5.dfsg.1.orig/libicmp/icmp_timestamp.c 2008-07-10 17:37:31.000000000 +0000
++++ inetutils-1.5.dfsg.1/libicmp/icmp_timestamp.c 2008-07-10 17:37:41.000000000 +0000
+@@ -21,6 +21,7 @@
+ # include <config.h>
+ #endif
+
++#include <stdlib.h>
+ #include <sys/types.h>
+ #include <sys/socket.h>
+ #include <sys/time.h>

+1 for the implementation.

BTW, it installs its own verson of tools provided by other packages (e.g. ping) so they'll need to be removed from inetutils

Ill admit i got the idea from Crux which replaced the utilities in its upcoming 2.5 version with inetutils.
As i can see in the ports tree you can enable only the tools you want http://crux.nu/ports/crux-2.5/core/inetutils/Pkgfile http://crux.nu/ports/crux-2.5/core/inetutils/

As for finger, http://www.gnu.org/software/finger points to inetutils. But finger is not part of it. http://www.gnu.org/cgi-bin/estseek.cgi?phrase=finger

I'd be for this. Seeing as we're using the GNU stack everywhere else.

How many packages will we be replacing with this? Some of them still may be useful (or not). Take for instance, tftp-hpa. We have two tftp implementations. Should both be removed, or just one?

Either way, I'm totally fine with doing this.

Good question.
It can replace at least the 4 netkit packages {ftp,tftp,telnet,rsh}
As far as inetd Archlinux already ships xinetd which is supposed to be inetd-ng. I am not familiar with it but it should be best to stay with xinetd. All posts on the internet, even though most are old, claim xinetd is best to use.
Theres also whois, but the one in extra seems to be better than the one in this package. Plus it seems to be actively maintained.
And, last but not least, theres ifconfig, ping etc which are part of our iputils. Which i dont think it should be replaced either. http://www.skbuff.net/iputils/ seems better maintained as well.
Maybe add tpowa who maintains the packages to this also.

BTW since inteutils also includes syslogd and seeing grml moved to using rsyslog, can i drop that on the table too? :)
Sergej seems to have a package for it in [community] http://aur.archlinux.org/packages.php?ID=20186
Heres a comparison list: http://www.rsyslog.com/doc-rsyslog_ng_comparison.html

Theres some interesting discussion on http://fedoraproject.org/wiki/Releases/FeatureRsyslog especially under the Why not syslog-ng paragraph

I would preferently remove the netkit tools where possible as they seem to be no longer maintained upstream. If there are other implementations in the repo, like tftp-hpa, we should check if it's orphaned and if it's better than the inetutils' one.

I would also prefer not replace the tools that iputils already provides.

The way I understand it is that syslogd is not the same as rsyslog. Sergej's package uses a different source. That should go in a different bug report.

I'll check what tools inetutils can provide and what packages could potentially be replaced by it. Once that'll be done, I'll post on the ML for input from the other devs/community. As we'll be replacing netkit-telnet from core, it'll eventually need to be brought up on the ML for comments/signoff anyway.

I opened a seperate feature request for rsyslog http://bugs.archlinux.org/task/12314
The package Sergej provides its the same as the one im referring to.
Besides the above i totally agree with Snowman. Ideally iputils will be replace with iproute in the future, as brain0 has already suggested in the arch-dev-public ML in the past.

Here's the list of the tools that inetutils can provide and the packages or part of packages that they could potentially replace. Discussion is below:
==================
--enable-ftpd
N/A

--enable-inetd
Could replace xinetd

--enable-rexecd
Could replace netkit-rsh

--enable-rlogind
Could replace netkit-rsh

--enable-rshd
Could replace netkit-rsh

--enable-syslogd
Could replace sysklogd partially : syslogd

--enable-talkd
N/A

--enable-telnetd
Could replace netkit-telnet

--enable-tftpd
Could replace netkit-tftp (a xinet daemon)
Could replace tftp-hpa (a rc.d daemon)

--enable-uucpd
N/A

--enable-ftp
Could replace netkit-ftp

--enable-ping
Could replace iputils partially : ping

--enable-ping6
Could replace iputils partially : ping6

--enable-rcp
Could replace netkit-rsh

--enable-rlogin
Could replace netkit-rsh

--enable-rsh
Could replace netkit-rsh

--enable-logger
Could replace util-linux-ng partially : logger

--enable-talk
N/A

--enable-telnet
Could replace netkit-telnet (a xinet daemon)

--enable-tftp
Could replace netkit-tftp
Could replace tftp-hpa

--enable-whois
Could replace whois

--enable-ifconfig
Could replace net-tools partially : ifconfig
==================

Point A) If we decide to not replace parts of packages in the repo, then we disable syslogd, ping, ping6, logger and ifconfig.
Point B) From Greg comments, we should keep the current xinetd and whois standalone packages. So we disable inetd and whois.

tftp: inetutils'tftp is to be run via xinetd like netkit-tftp. tftp-hpa uses a rc.d daemon script. I don't know what is best and if it's something we should worry about. In fact, I don't know anything about xinetd so I'll need to read docs to get the daemon setup correctly. Does anyone has experience in xinetd-style daemon script?

About the talk{d}: we recently moved netkit-talk to unsupported. Do we build them in inetutils?

ftpd: do we add the ftp daemon? We already have several of these (probably better ones) in extra. There won't be any conflict so we could still add it.

uucpd: I don't know what it does. Do we add it?

I wanted to raise these points before going to the ML. If we agree on point A & B, we could limit the discussions to a small subset of these tools. I could always bring everything on the ML.

BTW, I don't have any experience with several of these clients/servers, so help in creating the deamon file (especially the xinetd ones) or testing might be necessary. FTR, I have PKGBUILD draft.

I have no idea about tftp-hpa or uucpd.
But replacing xinetd is more complex than it seems as many packages have /etc/xinetd.d/ scripts (eg. rsync) and would include rebuilding many packages (if someone uses ABS he can check exactly how many). But as i said before it doesnt seem appropriate.

Maybe we should move this to the devlist - I'm sure we can get more informed opinions about this there

!00%. I suggested from the start to add tpowa to this FR. I am almost certain that brain0 will have something to say about this too.