Summary: | guard against stray EPREFIX variable?? | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Jeremy Olexa (darkside) (RETIRED) <darkside> |
Component: | Prefix Support | Assignee: | 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)
2009-10-29 01:12:01 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? 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. (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/ (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? (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. 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. 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. |