From owner-freebsd-arch@FreeBSD.ORG Sat Nov 12 23:23:48 2011 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 173ED106566B for ; Sat, 12 Nov 2011 23:23:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id E195215209E; Sat, 12 Nov 2011 23:23:47 +0000 (UTC) Message-ID: <4EBF0003.3060401@FreeBSD.org> Date: Sat, 12 Nov 2011 15:23:47 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Ed Schouten References: <20111110123919.GF2164@hoeg.nl> <4EBC4B6E.4060607@FreeBSD.org> <20111111112821.GP2164@hoeg.nl> <4EBDC06F.6020907@FreeBSD.org> <20111112103918.GV2164@hoeg.nl> In-Reply-To: <20111112103918.GV2164@hoeg.nl> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: The strangeness called `sbin' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 23:23:48 -0000 On 11/12/2011 02:39, Ed Schouten wrote: > Hi Doug, > > * Doug Barton , 20111112 01:40: >>> But the point is: there are quite some tools in */sbin that should be >>> moved to */bin. I can at least point out 15 of them. >> >> Why don't we discuss those specifics first? > > In my opinion at least the following binaries are candidates of apps > that can be moved from sbin to bin, as they all work to some degree > without root privileges: The idea behind sbin isn't "needs root privileges." From hier(7): /sbin/ system programs and administration utilities fundamental to both single-user and multi-user environments > - ac > - arp > - config > - daemon > - dmesg > - ifconfig > - jls > - kldstat > - lastlogin > - md5 > - mtree > - ping > - ping6 > - pkg_info > - pkg_version > - pstat > - rcorder > - rmd160 > - sendmail > - sha1 > - sha256 > - sysctl Except for the hash tools (md5, etc.) those are all properly located in sbin. >> For those individual tools, yes. But you're discounting the collateral >> damage. > > Being? User confusion, conflict between how things are done in the base vs. how they are done in ports, problems for users who install stuff in /sbin and/or /usr/sbin, and the other problems that have been mentioned in this thread. >> Um, if 'make installworld' were to delete existing stuff that would be >> an overwhelming POLA violation. > > But my patch doesn't do that. Please take a look at what it does. The > user is kindly asked to move the binaries himself. Otherwise `make > installworld' simply refuses to run. Yeah, I saw that, which is why I was confused. I would argue that what you're proposing is also a POLA violation, although perhaps less so. > Unrelated to that, `make installworld' already deletes existing files > from the DESTDIR: > > - /.profile > - /.cshrc Do you have a reference? I had to add code to mergemaster to handle installing updates to them, fixing the symlinks, etc. > - /sys Are you sure that this happens on an already installed system? I know I've had to update this link on systems where I've moved my src tree. > - Some man/nls-related files. Not sure about these. Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/