Date: Sat, 16 Oct 2004 01:04:06 -0700 From: "David O'Brien" <obrien@FreeBSD.org> To: Makoto Matsushita <matusita@jp.FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/compat/compat4x.alpha libc.so.4.bz2.uu libc_r.so.4.bz2.uu libhistory.so.4.bz2.uu libm.so.2.bz2.uu libopie.so.2.bz2.uu libpcap.so.2.bz2.uu libperl.so.3.bz2.uu libreadline.so.4.bz2.uu Message-ID: <20041016080406.GC77261@dragon.nuxi.com> In-Reply-To: <20041016153725S.matusita@jp.FreeBSD.org> References: <20041013195615.GC90229@dragon.nuxi.com> <20041016113048M.matusita@jp.FreeBSD.org> <20041016061745.GA77261@dragon.nuxi.com> <20041016153725S.matusita@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 16, 2004 at 03:37:25PM +0900, Makoto Matsushita wrote: > Maybe it's ok with /{s,}bin and other binaries those come from ports, > but how about user-made custom binaries for their system backups or > host administration related tools? They also live somewhere in /. > > As we can easily comes "Since they also have a source, just recompile > them all" solution, but I'm afraid that that's not ok... If these user-made custom binaries were installed in /[s]bin, I think we can assume the user/sysadmin is capable of coping any needed .so's from /usr/lib/compat to /lib. In fact, this custom binary may easily had a .so usage for a lib we have in /usr/lib vs. /lib because none of the stock /[s]bin binaries need it. So the user/sysadmin has already had to deal with the issue by hand. -- -- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041016080406.GC77261>