Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 290960

Summary: guard against stray EPREFIX variable??
Product: Gentoo/Alt Reporter: Jeremy Olexa (darkside) (RETIRED) <darkside>
Component: Prefix SupportAssignee: Gentoo Prefix <prefix>
Status: RESOLVED LATER    
Severity: enhancement    
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-10-29 01:12:01 UTC
Should this be added to prefix.eclass such that ebuilds using EPREFIX should inherit prefix.eclass? This is an interim guard until portage properly knows about EPREFIX.

%% cvs di prefix.eclass 
Index: prefix.eclass
===================================================================
RCS file: /var/cvsroot/gentoo-x86/eclass/prefix.eclass,v
retrieving revision 1.1
diff -u -r1.1 prefix.eclass
--- prefix.eclass       2 Apr 2009 17:36:53 -0000       1.1
+++ prefix.eclass       29 Oct 2009 01:10:28 -0000
@@ -19,10 +19,9 @@
 # hence this eclass has nothing to do here in that case.
 # Note that setting EPREFIX in the environment with Prefix Portage sets
 # Portage into cross-prefix mode.
-if [[ ! ${EPREFIX+set} ]]; then
-       export EPREFIX=''
-fi
-
+pkg_setup() {
+       use prefix || EPREFIX=""
+}
 
 # @FUNCTION: eprefixify
 # @USAGE: <list of to be eprefixified files>
@@ -48,5 +47,5 @@
        return 0
 }
 
-
+EXPORT_FUNCTIONS pkg_setup
 # vim: tw=72:
Comment 1 Michael Haubenwallner (RETIRED) gentoo-dev 2009-10-29 07:57:05 UTC
(In reply to comment #0)
> Should this be added to prefix.eclass such that ebuilds using EPREFIX should
> inherit prefix.eclass? This is an interim guard until portage properly knows
> about EPREFIX.

Hmm, I don't see how this would guard anything:
* If prefix.eclass is inherited, it ensures EPREFIX is set in global scope already.
* When the ebuild overrides pkg_setup, EPREFIX won't be set.

Other than that:

> +pkg_setup() {
> +EXPORT_FUNCTIONS pkg_setup

Doesn't EXPORT_FUNCTIONS require ${ECLASS}_pkg_setup to be defined?
Comment 2 Fabian Groffen gentoo-dev 2009-10-29 08:25:59 UTC
Problem is that also in Prefix, if you set EPREFIX in your environment, you might screw up things, simply because that overrides the setting of EPREFIX that Portage would default to.  It's like ROOT.
Comment 3 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-10-29 18:11:09 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > Should this be added to prefix.eclass such that ebuilds using EPREFIX should
> > inherit prefix.eclass? This is an interim guard until portage properly knows
> > about EPREFIX.
> 
> Hmm, I don't see how this would guard anything:
> * If prefix.eclass is inherited, it ensures EPREFIX is set in global scope
> already.

The problem is for ebuild in gentoo-x86 that use EPREFIX. Let's consider some ebuild that has --docdir="${EPREFIX}/usr/share/doc". If the user running Gentoo Linux, has EPREFIX="/path/on/root/" then the installation is broken and installs docs to /path - undesired effect.

> * When the ebuild overrides pkg_setup, EPREFIX won't be set.

Of course, as with all eclasses, if you override the eclass in the ebuild then it needs to call prefix_pkg_setup
> 
> Other than that:
> 
> > +pkg_setup() {
> > +EXPORT_FUNCTIONS pkg_setup
> 
> Doesn't EXPORT_FUNCTIONS require ${ECLASS}_pkg_setup to be defined?

s/^pkg_setup/prefix_pkg_setup/
Comment 4 Fabian Groffen gentoo-dev 2009-11-11 16:11:44 UTC
(In reply to comment #3)
> The problem is for ebuild in gentoo-x86 that use EPREFIX. Let's consider some
> ebuild that has --docdir="${EPREFIX}/usr/share/doc". If the user running Gentoo
> Linux, has EPREFIX="/path/on/root/" then the installation is broken and
> installs docs to /path - undesired effect.

Isn't that the same for us?
Comment 5 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-11-11 16:43:14 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > The problem is for ebuild in gentoo-x86 that use EPREFIX. Let's consider some
> > ebuild that has --docdir="${EPREFIX}/usr/share/doc". If the user running Gentoo
> > Linux, has EPREFIX="/path/on/root/" then the installation is broken and
> > installs docs to /path - undesired effect.
> 
> Isn't that the same for us?
> 

Yes, but it is a much larger problem if someone hits it in gx86 and has no clue why ebuilds are failing to do what they expect. Gentoo Prefix users know about the special variable from the beginning. Gentoo Linux users don't need to know that EPREFIX is special.

BTW, this has already happened once before. Someone was getting help in #gentoo-dev-help IIRC.
Comment 6 Fabian Groffen gentoo-dev 2009-11-11 19:59:28 UTC
I still think we can shortcut this.  The council has decided they have no idea what it's all about they so they preferred not to solve this for us.  I don't think inheriting prefix in every ebuild we migrate is a good idea.  But if the majority thinks it /is/ I won't refuse to do so.
Comment 7 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-11-11 21:18:32 UTC
Right, I don't really care to be honest. *I* won't have the stray EPREFIX variable in my env :) Just hoping to save a few headaches for other users. A nice side effect would be that ebuilds won't need 'use prefix || EPREFIX="" ' - but meh. I know that this doesn't save Gentoo Prefix users from hurting themselves but it does save Gentoo Linux users from hurting themselves.