svn commit: r314464 - head/usr.sbin/yppush

[Rodney W. Grimes]

[ Charset UTF-8 unsupported, converting... ]
> On Wed, Mar 1, 2017 at 9:08 AM, Rodney W. Grimes
> <freebsd-rwg at pdx.rh.cn85.dnsmgr.net> 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 <gjb at FreeBSD.org>
> 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 at freebsd.org