Date: Wed, 1 Mar 2017 09:08:09 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: Alexey Dokuchaev <danfe@FreeBSD.org>, src-committers <src-committers@FreeBSD.org>, Ian Lepore <ian@FreeBSD.org>, svn-src-all@FreeBSD.org, "Ngie Cooper (yaneurabeya)" <yaneurabeya@gmail.com>, svn-src-head@FreeBSD.org, Ngie Cooper <ngie@FreeBSD.org> Subject: Re: svn commit: r314464 - head/usr.sbin/yppush Message-ID: <201703011708.v21H89XW057584@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <20170301165916.kuizbr2w5l2beoac@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
-- Start of PGP signed section.
> On Wed, Mar 01, 2017 at 08:43:55AM -0800, Rodney W. Grimes wrote:
> > > On Wed, Mar 01, 2017 at 08:54:51AM -0700, Ian Lepore wrote:
> > > > ...
> > > > You're not the only one who has diffed build output logs (I suspect
> > > > anyone who has to maintain a non-trivial build infrastructure has done
> > > > so), and you're not the only one who thinks that changing relative
> > > > paths to absolute is a bad idea.
> > >
> > > +1. Relative paths are so much nicer (and they are usually shorter as
> > > well). I didn't respond to these changes only because .CURDIR itself
> > > is expanded to a full path, so arguing if one wants some ../../ within
> > > what's inherently starts with a slash seems pointless.
> >
> > True, in the normal use relative paths are shorter, but in how this
> > actually all goes about the use of ${SRCTOP} vs ${.CURDIR} yeilds
> > both short strings in the Makefile, and shorter output in the log.
>
> And making the logs with relative path would actually be hard given how make
> works or maybe I'm missing something
Yes, iirc even the output from make -n well have the pathnames all
expanded to full lengths. I dont believe there is any short way
to fix that.
> > Your reasoning is also why I was somewhat quiet on it when I saw it
> > start to be merged into -stable, which was the first place I saw it.
> > I *thought* at that point the whole of -current had already been
> > converted and this was just coming over with other nearby changes.
> >
> > I believe we have some other full path things that have crept
> > forward into the production release, but that may be in ports
> > only. Nope bad full paths links I found in just a few seconds:
> >
> > lrwxr-xr-x 1 root wheel 15 Nov 30 02:26 chfn -> /usr/bin/chpass
> > lrwxr-xr-x 1 root wheel 15 Nov 30 02:26 chsh -> /usr/bin/chpass
> > lrwxr-xr-x 1 root wheel 7 Nov 30 02:27 cpio -> bsdcpio
> > lrwxr-xr-x 1 root wheel 21 Nov 30 02:27 mailq -> /usr/sbin/mailwrapper
> > lrwxr-xr-x 1 root wheel 21 Nov 30 02:27 newaliases -> /usr/sbin/mailwrapper
> > lrwxr-xr-x 1 root wheel 10 Nov 30 02:25 pgrep -> /bin/pgrep
> > lrwxr-xr-x 1 root wheel 10 Nov 30 02:25 pkill -> /bin/pkill
> > lrwxr-xr-x 1 root wheel 6 Nov 30 02:27 tar -> bsdtar
> > lrwxr-xr-x 1 root wheel 15 Nov 30 02:26 ypchfn -> /usr/bin/chpass
> > lrwxr-xr-x 1 root wheel 15 Nov 30 02:26 ypchpass -> /usr/bin/chpass
> > lrwxr-xr-x 1 root wheel 15 Nov 30 02:26 ypchsh -> /usr/bin/chpass
> > lrwxr-xr-x 1 root wheel 15 Nov 30 02:27 yppasswd -> /usr/bin/passwd
> >
> > This breaks the abilty to mv usr/bin and have the right stuff
> > happen if you invoke usr/bin.moved/mailq.
>
> Almost every was with absolute path for the symlinks, we have changed "recently"
> most (all?) of the symlinks for libraries (.so files) into relative to be able
> to have a proper sysroot, and yes I agree we should go further and make all the
> symlinks relative which is very easy install just add the option -l sr and magic
> happen :)
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.
--
Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201703011708.v21H89XW057584>