Skip site navigation (1)Skip section navigation (2)
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>