Date: Sun, 5 Mar 2017 23:30:36 +0800 From: Julian Elischer <julian@freebsd.org> To: Baptiste Daroussin <bapt@freebsd.org> Cc: rgrimes@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r314693 - head/usr.sbin/rmt Message-ID: <ada706dc-6564-cff5-d8b9-e81cb1ce4111@freebsd.org> In-Reply-To: <20170305152048.gyilvy7qscqg45hr@ivaldir.net> References: <201703051319.v25DJSGt082916@pdx.rh.CN85.dnsmgr.net> <761e6ecf-89aa-6356-4650-08f3c5c9d6a8@freebsd.org> <20170305152048.gyilvy7qscqg45hr@ivaldir.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/3/17 11:20 pm, Baptiste Daroussin wrote: > On Sun, Mar 05, 2017 at 11:11:35PM +0800, Julian Elischer wrote: >> On 5/3/17 9:19 pm, 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 >>>>> Approved by: grehan >>>>> MFC after: 1 week >>>>> >>>>> Modified: >>>>> head/usr.sbin/rmt/Makefile >>>>> >>>>> Modified: head/usr.sbin/rmt/Makefile >>>>> ============================================================================== >>>>> --- 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= 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? >>> >>> find /usr/share/mk/ | xargs grep INSTALL_RSYM >>> /usr/share/mk/bsd.own.mk:INSTALL_RSYMLINK?= ${INSTALL} ${RSYMLINK} >>> /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} ${DESTDIR}${_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} ${DESTDIR}${_SHLIBDIR}/${SHLIB_NAME} \ >>> >>> This is called from within bsd.lib.mk only, do we want to use this for >>> 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. >> I've been playing around with libpathconv which converts abs paths to >> relative paths etc. >> I'w working on the patch to ln to add the -a and -r options that some other >> versions have. >> >> you can specify an absolute path but ln -r (abspath) will generate a >> relative link. >> my target was the exact absolute symlinks that you are targeting. >> >> Work commitments have made me lay down tools but this reminds me to pick it >> up again. >> (libpathconv is in the tree at /lib/libpathconv, but I got interrupted half >> way through.. >> I'll do the other half.. > But install -l rs does exactly that, why adding a new mechanism? and install > works with metalog as stated earlier so for the build system it might be better. > > Which reminds me multiple people have asked you if it won't be a good idea to > merge your libpathconv into libutil rather that having a new library for just 2 > functions. DSO has a price and you haven't replied, will you consider merging > it? > > Best regards, > Bapt I will put it in libutil, but don't want to thrash too much so I'll do that with the ln patch. I hadn't thought that was a possibility originally. I need the ln patch myself and there are other systems that have it so I'm happy to do the work. if install can do that I'm happy to hear it. Nice to learn about it.. Does that mean that libpathconv is already somewhere in our system as install is of the programs that was changed in hte initial pathconv release many years ago.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ada706dc-6564-cff5-d8b9-e81cb1ce4111>