| Summary: | sys-apps/portage: automatically handle variance in var/db/pkg/*/*/EPREFIX | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Zac Medico <zmedico> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 193766 | ||
|
Description
Zac Medico
2021-03-07 03:48:25 UTC
For venv prefix mode, I'll also make setup.py patch paths in default config files to begin with ${EPREFIX}, in order to ensure that everything appropriate is assumed to be inside ${EPREFIX} for the default configuration.
(In reply to Zac Medico from comment #1) > For venv prefix mode, I'll also make setup.py patch paths in default config > files to begin with ${EPREFIX}, in order to ensure that everything > appropriate is assumed to be inside ${EPREFIX} for the default configuration. Note that these ${EPREFIX} references must be expanded at runtime, since it is not possible for files installed by pip to contain absolute paths (attempts to use absolute paths lead to invalid values as an artifact of the wheel build process). I assume this is only targetting python installs or something? Many programs aren't relocatable, but I'm also wondering if this is an env that other programs accessing the VDB are supposed to work. They will obviously have to be changed when CONTENTS no longer points an existing path. That said, if venv is completely focussed on a new use-case/scenario where this works fine, just ignore me :) (In reply to Fabian Groffen from comment #3) > I assume this is only targetting python installs or something? This is really about fitting into the venv better. Portage is forced to dynamically evaluate ${EPREFIX} because a pip wheel installs will not work otherwise. So, it would be inconsistent to include EPREFIX in contents entries when ${EPREFIX} is dynamically evaluated. > Many programs aren't relocatable, That's fine. Still, I'd prefer to have either a dynamic or static EPREFIX, rather than an inconsistent mixture of dynamic and static. > but I'm also wondering if this is an env that > other programs accessing the VDB are supposed to work. They will obviously > have to be changed when CONTENTS no longer points an existing path. How many other programs are you aware of that access a VDB inside of a venv? I tried pkgcore in a venv just now, and pmerge seems to behave as if there is no prefix. > said, if venv is completely focussed on a new use-case/scenario where this > works fine, just ignore me :) The only use-case defined at this point is for bug 629048, and for that there's no plan to emerge packages into the venv prefix. (In reply to Zac Medico from comment #4) > (In reply to Fabian Groffen from comment #3) > > I assume this is only targetting python installs or something? > > This is really about fitting into the venv better. Portage is forced to > dynamically evaluate ${EPREFIX} because a pip wheel installs will not work > otherwise. So, it would be inconsistent to include EPREFIX in contents > entries when ${EPREFIX} is dynamically evaluated. > > > Many programs aren't relocatable, > > That's fine. Still, I'd prefer to have either a dynamic or static EPREFIX, > rather than an inconsistent mixture of dynamic and static. Consistency is good, no discussion about that. EPREFIX should be stored in the VDB per package, so that would also work. > > but I'm also wondering if this is an env that > > other programs accessing the VDB are supposed to work. They will obviously > > have to be changed when CONTENTS no longer points an existing path. > > How many other programs are you aware of that access a VDB inside of a venv? > I tried pkgcore in a venv just now, and pmerge seems to behave as if there > is no prefix. /inside/ a venv, I don't know (I'll admit I don't quite grok yet how this work). Obviously, tools like portage-utils are parsing the CONTENTS file, for tools like qfile. Again, if this won't be affected ever, then there's no need to educate me or discuss this further. > > said, if venv is completely focussed on a new use-case/scenario where this > > works fine, just ignore me :) > > The only use-case defined at this point is for bug 629048, and for that > there's no plan to emerge packages into the venv prefix. Ok, I'm assuming this allows from another (non-Gentoo) machine to fire up Portage installed using pip with --fetch-only or something to get distfiles downloaded or recorded or something, as opposed to emerge -pDU --print-fetch-urls @world or something. I guess what triggered me is whether or not CONTENTS is going to be changed to exclude EPREFIX from the object paths. If yes, I'll have to do some work for this, if not, there's absolutely nothing I have business with here. (In reply to Fabian Groffen from comment #5) > (In reply to Zac Medico from comment #4) > > How many other programs are you aware of that access a VDB inside of a venv? > > I tried pkgcore in a venv just now, and pmerge seems to behave as if there > > is no prefix. > > /inside/ a venv, I don't know (I'll admit I don't quite grok yet how this > work). Obviously, tools like portage-utils are parsing the CONTENTS file, > for tools like qfile. Again, if this won't be affected ever, then there's > no need to educate me or discuss this further. I'm thinking that we could apply this CONTENTS change to the prefix branch as well, since it's easy to distinguish whether or not the paths begin with EPREFIX. Both formats are basically interchangeable. > > > said, if venv is completely focussed on a new use-case/scenario where this > > > works fine, just ignore me :) > > > > The only use-case defined at this point is for bug 629048, and for that > > there's no plan to emerge packages into the venv prefix. > > Ok, I'm assuming this allows from another (non-Gentoo) machine to fire up > Portage installed using pip with --fetch-only or something to get distfiles > downloaded or recorded or something, as opposed to emerge -pDU > --print-fetch-urls @world or something. > > I guess what triggered me is whether or not CONTENTS is going to be changed > to exclude EPREFIX from the object paths. If yes, I'll have to do some work > for this, if not, there's absolutely nothing I have business with here. Well, how would you feel about making both CONTENTS formats interchangeable? If paths don't begin with ${EPREFIX}, then we translate them during CONTENTS parsing. Now that I realize they're interchangeable, I think don't want to change the CONTENTS format, since instead I can be tolerant to EPREFIX variance in the VDB. If you feel you must ... ok, but then instead of trying to rely on "path does not start with EPREFIX" let's make the paths non-absolute, e.g. strip the leading / from them, such that it very obvious they need to be fitted onto a root. EPREFIX is part of the VDB in Prefix branch, so q can simply join EPREFIX + CONTENTS when the entry in CONTENTS doesn't start with '/'. Alternatively, should we consider using CONTENTS.2 instead or something? |