[arch-dev-public] iputils & traceroute packaging
Quick question for whoever is responsible: Why on earth do we have a separate traceroute package that is not a part of base? This seems to fit much better being in the iputils package, although I am not familiar with the sources of these packages and why they are developed separately. $ pacman -Ql traceroute traceroute /usr/bin/traceroute traceroute /usr/man/man8/traceroute.8.gz $ pacman -Ql iputils iputils /bin/ping iputils /bin/ping6 iputils /etc/protocols iputils /etc/services iputils /usr/man/man8/arping.8.gz iputils /usr/man/man8/clockdiff.8.gz iputils /usr/man/man8/ping.8.gz iputils /usr/man/man8/rarpd.8.gz iputils /usr/man/man8/rdisc.8.gz iputils /usr/man/man8/tftpd.8.gz iputils /usr/man/man8/tracepath.8.gz iputils /usr/man/man8/traceroute6.8.gz iputils /usr/sbin/arping iputils /usr/sbin/clockdiff iputils /usr/sbin/rarpd iputils /usr/sbin/rdisc iputils /usr/sbin/tftpd iputils /usr/sbin/tracepath iputils /usr/sbin/tracepath6 iputils /usr/sbin/traceroute6 What I find really weird is the inclusion of traceroute6 in iputils. This all came up while going about "fixing" this bug: <http://bugs.archlinux.org/task/6725> I don't want to make mtr setuid unless we are going to make traceroute suid. mtr > traceroute > ping, so it should be at no higher of a level than the one below it. What should we be installing programs like this as? I think it makes sense to have ping and traceroute available to a user, so maybe they should all be SUID, currently traceroute6 is not. Comments and thoughts appreciated. -Dan
participants (1)
-
Dan McGee