From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E62E81381F3 for ; Sun, 2 Jun 2013 12:50:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2C6C8E09B1; Sun, 2 Jun 2013 12:50:33 +0000 (UTC) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5E994E099F for ; Sun, 2 Jun 2013 12:50:32 +0000 (UTC) Received: by mail-bk0-f49.google.com with SMTP id 6so1437341bkj.8 for ; Sun, 02 Jun 2013 05:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=W/8/N6WnEyoWJ6eD5f3249ujSbkmsTgBFdzJ+iJ+sZM=; b=luS9uGsZ3ts41FeF6VgX0CM4jQv830z/fmk1utHz+g8W6d/b7wvaFK78BKkrkXHuOP NRSTUvuD+agxSf5EtHElpTMZOgb0f0t5R3AXjIOrPI5WjgQaXz6DvHEDdlgMg/sZW8Z1 1t/tC3Q8k0Z9z4TXS1XMnvtjFQ8wj6W+DfG9K9dE7ilkYEtfUVgLBMrtiyNxtLRd2mof Ot3wCAVqfqSLTGqVZYZ9LBFvgfBJ1RF5ZJ5iOu3TULlHQR7MFNqAW1KOxamvywb6HEu4 ndprkkCw+qgoDCZ3vGEPFy2tGsP6XpIU/O5DWerAqE0swM0yhk/8OBXG6HNhvNx0xHpw 6N9Q== X-Received: by 10.204.241.66 with SMTP id ld2mr4347937bkb.157.1370177430823; Sun, 02 Jun 2013 05:50:30 -0700 (PDT) Received: from [192.168.4.18] ([5.157.117.94]) by mx.google.com with ESMTPSA id og1sm14267372bkb.16.2013.06.02.05.50.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Jun 2013 05:50:29 -0700 (PDT) Message-ID: <51AB3EFA.7000905@gmail.com> Date: Sun, 02 Jun 2013 14:47:54 +0200 From: "vivo75@gmail.com" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130517 Thunderbird/17.0.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org CC: Duncan <1i5t5.duncan@cox.net> Subject: Re: [gentoo-portage-dev] Re: Is portage (/usr)/bin-merge safe? References: <51AB2921.2060906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 87b622be-6238-4702-8e99-a68ea62af3a5 X-Archives-Hash: fc383a62c9db5dcf5eb2d1c817b92be5 On 06/02/13 13:54, Duncan wrote: > vivo75@gmail.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)