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 242761381F3 for ; Sun, 2 Jun 2013 11:55:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B5D62E0984; Sun, 2 Jun 2013 11:55:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EEAC9E0983 for ; Sun, 2 Jun 2013 11:55:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2EDA433E329 for ; Sun, 2 Jun 2013 11:55:01 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5.5 tests=[AWL=-0.749, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.07, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCzgcV3Do7Bp for ; Sun, 2 Jun 2013 11:54:55 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 1A3D033E328 for ; Sun, 2 Jun 2013 11:54:52 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Uj6s5-00063X-9J for gentoo-portage-dev@gentoo.org; Sun, 02 Jun 2013 13:54:49 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 02 Jun 2013 13:54:49 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 02 Jun 2013 13:54:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-portage-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-portage-dev] Re: Is portage (/usr)/bin-merge safe? Date: Sun, 2 Jun 2013 11:54:33 +0000 (UTC) Message-ID: References: <51AB2921.2060906@gmail.com> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT b00f96e /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 9a32fa3c-cd1b-4dfe-9874-f0afbf1ea0b0 X-Archives-Hash: 38dc08e88e756e90b8dc543a22603320 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.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman