Re: [gentoo-portage-dev] Re: Is portage (/usr)/bin-merge safe?

On 06/02/13 13:54, Duncan wrote:
> vivo75@×××××.com posted on Sun, 02 Jun 2013 13:14:41 +0200 as excerpted:
>
>> While portage can be safe, for various reason (including the resultant
>> pkg) I do prefer to do the move in post_src_install() #1 All my tests
>> have been done against a manually converted filesystem
> That's what mine would be...
>
>> #1 excerpt from bashrc, this code is rough but work in the gentoo
>> ebuilds tree domain
>>
>> move_root_to_usr() {
> Thanks.  What I was thinking would actually reverse that (/bin being the
> real dir, /sbin being a symlink to it), given my (traditional sysadmin)
> pref for short paths, but I hadn't thought of a bashrc solution at all,
> so that gives me yet another way of doing it. =:^)
>
> My first thought is that I prefer standard layout packages, however,
> easing interoperability should I decide to swap binpkgs with someone.
> (Yes, I'm aware of the security issues if the parties don't trust each
> other...)
>
> But OTOH I think that solves issues such as path-based equery belongs,
> for instance.  Being amd64 for nearing a decade now (and no-multilib for
> several years of it), I'm used to worrying about that with the symlinked
> lib/lib64 thing, and that's the one thing I wasn't looking forward to
> with unified bins.  (I think I'll keep bin/sbin separate at first, see
> how bin/usr-bin go first, then think about bin/sbin.)
>
> But if your bashrc solution /does/ solve the equery belongs path thing I
> might well use it on lib/lib64 as well...  (Either that or since I
> believe the libs are a profile thing and I'm already running a heavily
> modified profile, no @system for instance, I could probably simply modify
> that...  Actually, that's probably a better solution in any case, since
> it's just undoing mainline settings the same way mainline does them in
> the first place.)

I do generally leave profiles untouched but yes it could be a solution,
maybe some research in debian maillist could be beneficial too.
In the meantime these commands results should tell you about equery belongs:

>hom>vivo$ qlist coreutils | grep -c '^/bin/'
0
>hom>vivo$ qlist coreutils | grep -c '^/usr/bin/'
101

>hom>vivo$ equery belongs /usr/bin/sleep
 * Searching for /usr/bin/sleep ...
sys-apps/coreutils-8.21 (/usr/bin/sleep)