Date: Sun, 5 Mar 2017 16:34:48 +0100 From: Baptiste Daroussin <bapt@freebsd.org> To: Julian Elischer <julian@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, rgrimes@freebsd.org Subject: Re: svn commit: r314693 - head/usr.sbin/rmt Message-ID: <20170305153448.6trjgu7u3yj6phjm@ivaldir.net> In-Reply-To: <ada706dc-6564-cff5-d8b9-e81cb1ce4111@freebsd.org> References: <201703051319.v25DJSGt082916@pdx.rh.CN85.dnsmgr.net> <761e6ecf-89aa-6356-4650-08f3c5c9d6a8@freebsd.org> <20170305152048.gyilvy7qscqg45hr@ivaldir.net> <ada706dc-6564-cff5-d8b9-e81cb1ce4111@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Sun, Mar 05, 2017 at 11:30:36PM +0800, Julian Elischer wrote: > 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. Thank you > > 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. To be clear I'm happy with ln(1) growing with such functionality. I'm just saying that in this specific case install -l rs is more appropriated :) Best regards, Bapt [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAli8MBAACgkQY4mL3PG3 Plo5DxAArciZwtZBw84eDUxraNRKzZExpWrRb0mnwKHgwAaL12Y+P+eUN5qS0J/W 4PcY9hbAvnGEc1YU1FHx+8fu7BSImvj7RZwMGz009JoUF7cbBftoMxEeYry3mvrM QI9fTPF4jG19RngI4T4IPRE/ed0erD5JCT103I9DD60O8zFqnFWnD9XV9UlLYXYR xWqTkzDIlLwgZx05fBc/aT3qlLB+nCISdfmjZpGN8DxMWFTKAvvPIArHz6YqPL41 1SMzIu8wZZjT/Lu/Co3Aa0kBzh7UatRawMcT34BnGBLODpkyLPark0CUrvvC31uJ /EFe7R40U8gJmHmVqw+sdjsawX1sgAYI9TRw/vWUkToGZmKvJXqTDmJJTHzUFH10 w/Oajmih049hG/JUfbkZoE2/b4oWilCNtjkzFSMKJYEfMCBGd9puuLbDDlUNE7ZK ZhHg8Vxp3yyyfwj6WzMFfRQTpLfDikvMt0Bx0ClQV8un+moDlHOI+HWcawHz6z8y kkSJBi9IkXJH9zbjnP4Yt9mEJ8pvjrLcciyfQGYb9h+t2vFCD5e49i5l8cki5E/M 1mab4v2oOmwsqXKrwDPjtZrQG8BGGcQTM3vmlsPUQkifz/K/L+bG78aVAJDkVnej 66NUuzEbt5py+o9cRRnEPQND5YDRmYUKh4oNQWlDtMR4fgOlRyc= =9VyL -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170305153448.6trjgu7u3yj6phjm>