From owner-freebsd-hackers@freebsd.org Sun Mar 5 21:15:42 2017 Return-Path: Delivered-To: freebsd-hackers@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 05518CFA2AF for ; Sun, 5 Mar 2017 21:15:42 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBC481517; Sun, 5 Mar 2017 21:15:41 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id E735E22BD; Sun, 5 Mar 2017 21:15:40 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 5739035C61; Sun, 5 Mar 2017 21:15:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id FTjrrTA5Fe1U; Sun, 5 Mar 2017 21:15:23 +0000 (UTC) Subject: Re: svn commit: r314693 - head/usr.sbin/rmt DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 2A8B735C5C To: rgrimes@freebsd.org, Baptiste Daroussin References: <201703051626.v25GQWNd083561@pdx.rh.CN85.dnsmgr.net> Cc: freebsd-hackers@freebsd.org From: Bryan Drewery Organization: FreeBSD Message-ID: <1283ca30-a827-8b32-3021-658548447c22@FreeBSD.org> Date: Sun, 5 Mar 2017 13:15:21 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <201703051626.v25GQWNd083561@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NKpRxNDOhNMeNIJIM17CONpFkP9s5hLsm" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Mar 2017 21:15:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NKpRxNDOhNMeNIJIM17CONpFkP9s5hLsm Content-Type: multipart/mixed; boundary="sc1C8DOpCx3wfL6vevMrDiRFHgHpjNQ98"; protected-headers="v1" From: Bryan Drewery To: rgrimes@freebsd.org, Baptiste Daroussin Cc: freebsd-hackers@freebsd.org Message-ID: <1283ca30-a827-8b32-3021-658548447c22@FreeBSD.org> Subject: Re: svn commit: r314693 - head/usr.sbin/rmt References: <201703051626.v25GQWNd083561@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201703051626.v25GQWNd083561@pdx.rh.CN85.dnsmgr.net> --sc1C8DOpCx3wfL6vevMrDiRFHgHpjNQ98 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/5/17 8:26 AM, Rodney W. Grimes wrote: > Moved thread to -hackers for a quick discussion. >=20 >> On Sun, Mar 05, 2017 at 05:19:28AM -0800, Rodney W. Grimes wrote: >>> -- Start of PGP signed section. >>>> On Sun, Mar 05, 2017 at 04:09:18AM +0000, Rodney W. Grimes wrote: >>>>> Author: rgrimes >>>>> Date: Sun Mar 5 04:09:18 2017 >>>>> New Revision: 314693 >>>>> URL: https://svnweb.freebsd.org/changeset/base/314693 >>>>> >>>>> Log: >>>>> Change /etc/rmt symlink from absolute to relative path, >>>>> correcting the mistake made in r6499 >>>>> =20 >>>>> Approved by: grehan >>>>> MFC after: 1 week >>>>> >>>>> Modified: >>>>> head/usr.sbin/rmt/Makefile >>>>> >>>>> Modified: head/usr.sbin/rmt/Makefile >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>> --- head/usr.sbin/rmt/Makefile Sun Mar 5 04:02:47 2017 (r314692) >>>>> +++ head/usr.sbin/rmt/Makefile Sun Mar 5 04:09:18 2017 (r314693) >>>>> @@ -7,6 +7,6 @@ MAN=3D rmt.8 >>>>> # called from /usr/src/etc/Makefile >>>>> etc-rmt: >>>>> rm -f ${DESTDIR}/etc/rmt >>>>> - ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt >>>>> + ln -s ..${BINDIR}/rmt ${DESTDIR}/etc/rmt >>>> >>>> I think this should be ${INSTALL_RSYMLINK} ${BINDIR}/rmt ${DESTDIR}/= etc/rmt >>> >>> find /usr/src | xargs grep INSTALL_RSYM >>> (no results) >>> >>> Sorry, no prior work does this, perhaps once I get done sweeping the >>> absolutes out of the tree (about 10 or 15 IIRC) a pass can be made to= >>> sweep all ln -s out and propage this internal bsd.lib.mk function out= >>> to the rest of the source tree? >> >> There is also no Makefiles that do ls -sf directly beside that one. > Unless I have missed a commit: > ./crypto/openssh/contrib/cygwin/Makefile: cd $(DESTDIR)$(mandir)/= man1 && ln -s ssh.1.gz slogin.1.gz > ./usr.sbin/sendmail/Makefile: ln -sf ${.ALLSRC} ${.TARGET} > ./usr.sbin/rmt/Makefile: ln -s ${BINDIR}/rmt ${DESTDIR}/etc/rmt > ... Keep in mind that INSTALL_*SYMLINK should only be used for *installing* a symlink, not for intermediate build files. All of the direct 'ln' usage in the tree should be not installed. Brooks and I and others have done passes before to ensure that any installed symlink uses INSTALL_*SYMLINK. The reasoning is that the -DNO_ROOT build requires that 'install' be used since it is logging the file in a meta log that is later used to build an image from. This is also important for the DIRDEPS_BUILD feature. > A summary is there are 50 instances of ln -sf, 28 other variants of ln= -s, > and 5 ln -fs. I did not search for other permutaions of ln and s f opt= ions. >=20 >=20 >> INSTALL_RSYMLINK has exactly be done to be use everywhere it is needed= =2E (I wrote >> it for that exact reason :)) >=20 > Wonderful!! I'll investigate a sweep to finish implementing this tree = wide > in my spare time.... I notice that SYMLINKS=3D is hard coded to use > INSTALL_SYMLINKS so that can't be used to fix some of these. > How would you propose I proceed in that area?? >=20 > And investigation into using INSTALL_RSYMLINK in SYMLINKS=3D should be = done, > I can not think of a reason when you DONT want a relative link install= ed, > but I may be missing some new odd use for symlinks by the FreeBSD base > system. >>> >>> find /usr/share/mk/ | xargs grep INSTALL_RSYM >>> /usr/share/mk/bsd.own.mk:INSTALL_RSYMLINK?=3D ${INSTALL} ${RSYMLI= NK} >>> /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS:D${TAG= _ARGS},development} ${SHLIB_NAME} ${DESTDIR}${_LIBDIR}/${SHLIB_LINK} >>> /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS} ${DES= TDIR}${_SHLIBDIR}/${SHLIB_NAME} \ >>> /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS:D${TAG= _ARGS},development} ${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \ >>> /usr/share/mk/bsd.lib.mk: ${INSTALL_RSYMLINK} ${TAG_ARGS} ${DES= TDIR}${_SHLIBDIR}/${SHLIB_NAME} \ >>> >>> This is called from within bsd.lib.mk only, do we want to use this fo= r >>> all symbolics links in the source tree? If so I would of though the >>> person adding this functionality to the .mk files would of made >>> a tree sweeping looking for that and making those changes as well. >> >> When I did it only bsd.lib.mk was using it iirc >=20 > And that appears to still be the case. >=20 >>>> The rm -f before can then be removed, the symlink will be relative a= nd the >>>> METALOG will be respected=20 >>> >>> METALOG? The only documentation I can find on this seems to be part = of >>> src/tootls/tools/makeroot.8. >>> >>> It appears that something in Makefile.inc uses it and there are refer= ences >>> to it in etc/Makefile. >>> >>> Where is this METALOG documented? =20 >> >> It is really badly documented and should be :( it is a mtree file that= is >> generated when built is done via -DNO_ROOT for the purpose of being ab= le to >> generate disk with makefs as a user >> >> I have reused it for packaging base. >> >> This was designed IIRC by adrian and brooks iirc. >> >> Embedded people relies a lot on it. >> Everything not going though the install(1) command is not tracked that= is why >> this is an issue. >=20 > I guess then that these 83 things I have found are not so important to = them? >=20 > Lets take this to -hackers, discuss it where it should be, and get it f= ixed. >=20 --=20 Regards, Bryan Drewery --sc1C8DOpCx3wfL6vevMrDiRFHgHpjNQ98-- --NKpRxNDOhNMeNIJIM17CONpFkP9s5hLsm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYvH/qAAoJEDXXcbtuRpfPkowIAKOBALSd8A9revHHonmA+Zny 6iOcwWHkgf1SsUA0iibAwOJffUWEEZxS9al1m/yoNmf9dH81u0wAAceor8P72Q7A /OEUw5aNbaBV2TzmqPRBOw52MGJHaIRPM6hAAkqvYCokHdJm4Zf8hY39lzZes0Jl 8ynoDUcUzGr3gHXVNLJGlma3kQpwOi9VoBFpGmYbfGdSWUEOZTCcO3NRx37qv03i 8W0RD0Dr4oMteufZyRccgzqZV0BxGMYpQLIbgs3Zhu71OA1q7D/PFJR4aQqOSSrT iIWNTi2R3rlgv+UloXYg0Jo9noq4xJLCn8zlq7fBAaNSx3WX3pLQpNZW+duzQHo= =D6xS -----END PGP SIGNATURE----- --NKpRxNDOhNMeNIJIM17CONpFkP9s5hLsm--