From owner-svn-src-head@freebsd.org Thu Mar 2 02:39:30 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23644CF4B85; Thu, 2 Mar 2017 02:39:30 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8DED2FB; Thu, 2 Mar 2017 02:39:29 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v222dShM060240; Wed, 1 Mar 2017 18:39:28 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v222dROG060239; Wed, 1 Mar 2017 18:39:27 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201703020239.v222dROG060239@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r314464 - head/usr.sbin/yppush In-Reply-To: To: Ngie Cooper Date: Wed, 1 Mar 2017 18:39:27 -0800 (PST) CC: Baptiste Daroussin , Alexey Dokuchaev , src-committers , Ian Lepore , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 02:39:30 -0000 [ Charset UTF-8 unsupported, converting... ] > On Wed, Mar 1, 2017 at 9:08 AM, Rodney W. Grimes > wrote: > ... > > At one point in history I can promise you that ALL symlinks in the release > > where shortest possible relative path. So any absolute links that entered > > the system got created by developers who where not aware that they should > > always use a relative link for anything landing in DESTDIR. This creates > > breakge on so many levels we should make a rapid correction to this > > regression. > > This is why things are that way currently: > > $ git blame usr.bin/chpass/Makefile| grep ypchfn > 780ae7713f72b (gjb 2016-01-28 01:15:57 +0000 29) SYMLINKS+= > ${BINDIR}/chpass ${BINDIR}/ypchfn Use of ${BINDIR} is almost always a mistake in SYMLINKS. > aca2488187113 (wosch 1997-09-13 12:21:25 +0000 35) MLINKS+= chpass.1 > ypchpass.1 chpass.1 ypchfn.1 chpass.1 ypchsh.1 > 5294f47313a2d (gjb 2016-01-28 02:56:30 +0000 39) .for i in chpass > chfn chsh ypchpass ypchfn ypchsh > $ git log 780ae7713f72b^..780ae7713f72b > commit 780ae7713f72b471859c0997295ac0c59695c7b4 > Author: gjb > Date: Thu Jan 28 01:15:57 2016 +0000 > > Ensure mtree(8) recognizes chpass(1) is schg. > > Convert hard links to symbolic links, and remove the > 'beforeinstall' and 'afterinstall' chflags(8) execution. > > Sponsored by: The FreeBSD Foundation > > Notes: > svn path=/projects/release-pkg/; revision=294966 > > BINDIR evaluates to /usr/sbin/, so /usr/sbin/chpass is symlinked to > /usr/sbin/ypchfn . But, there's no reason why the symlink needs to be > hardcoded, or even a symlink at all. Hardlinks would achieve the same > thing here IMHO, but gjb changed it in r294966 to be symlinks. The error is inclusion of ${BINDIR} in SYMLINKS. The BIGGER mistake uncovered here is now none of the aliases to chpass(1) are protected by schg(THis is a 10.2): ls -ilago /usr/bin/ | grep ^3842 3842 -r-sr-xr-x 6 root wheel schg 18316 Aug 12 2015 chfn 3842 -r-sr-xr-x 6 root wheel schg 18316 Aug 12 2015 chpass 3842 -r-sr-xr-x 6 root wheel schg 18316 Aug 12 2015 chsh 3842 -r-sr-xr-x 6 root wheel schg 18316 Aug 12 2015 ypchfn 3842 -r-sr-xr-x 6 root wheel schg 18316 Aug 12 2015 ypchpass 3842 -r-sr-xr-x 6 root wheel schg 18316 Aug 12 2015 ypchsh The reason for the commit seems to be an issue with mtree, so that is probably the more correct place to be tyring to fix this if it is confused by hardlinks and schg attributes. > The point that might be missed is that changing it from absolute paths > to relative paths or otherwise, might break other workflows.. I could > just as easily mount /lib, /usr/lib, /usr/sbin, etc as nullfs > mountpoints and have a working system on a system root where MACHINE > != TARGET, but this is all orthogonal to my changing > `${.CURDIR}/../../contrib` (e.g. `foo/usr.sbin/yppush/../../contrib`), > etc to ${SRCTOP}/contrib` (e.g. `foo/contrib`). Though you might make it work with lots of magic the expected historical behavior is that these things should not have absolute paths in them and many long standing work flows depend on that fact. Being able to move /usr/bin or /bin or any other part of the tree someplace and have it self contained and internally contained and operation is expected traditional behavior. > Thanks, > -Ngie > -- Rod Grimes rgrimes@freebsd.org