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 AB650138C9D for ; Tue, 2 Jun 2015 05:27:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8CE0BE0921; Tue, 2 Jun 2015 05:27:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0F7B3E0885 for ; Tue, 2 Jun 2015 05:27:46 +0000 (UTC) Received: by smtp.gentoo.org (Postfix, from userid 2274) id 2E699340C43; Tue, 2 Jun 2015 05:27:46 +0000 (UTC) Date: Tue, 2 Jun 2015 01:27:42 -0400 From: Tim Harder To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] [PATCH] make PORTAGE_BIN_PATH settings relocatable Message-ID: <20150602052742.GA24048@thor.home.lan> Mail-Followup-To: gentoo-portage-dev@lists.gentoo.org References: <1433140493-3288-1-git-send-email-vapier@gentoo.org> <20150601172524.GU4496@vapier> <20150601180108.GF18797@tarragon.analog.com> <20150602043117.GX4496@vapier> 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-Disposition: inline In-Reply-To: <20150602043117.GX4496@vapier> User-Agent: Mutt/1.5.22 (2013-10-16) X-Archives-Salt: db16e73c-bff2-4fe4-a521-d25dbacf26b0 X-Archives-Hash: 41ca364e60ffbb7a706da7bd9b6bb1ff On 2015-06-02 00:31, Mike Frysinger wrote: > > > (d) some other alternative ? > > If you're sticking with bash, there is also pkgcore's approach of using > > a custom shebang script that handles initialization and related generic > > things for most of the helpers. > shebangs have to be absolute which defeats the relocatable approach :( > although i could create a single wrapper script which would do the bootstrap and > then source the final script, and all the other tools would be symlinks to that. > like we do with newins/newbin/etc... Ah sure, so then you'd need to copy more of the underlying solution as well. In summary, currently a file (_const.py) gets generated at install time with all the relevant paths that can change. If that file doesn't exist (in git repos and unpacked tarballs) relative paths are used instead (and env overrides are supported as well if needed). The dir containing the shebang script is added to PATH for each ebuild process and /usr/bin/env is used to execute it in the shebangs. In short, it sort of combines a relocatable at install time approach with the inverse of portage's usage of its .portage_not_installed file. Tim