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

Bug 702134

Summary: [Future EAPI] query functions for ebuild-defined variables
Product: Gentoo Hosted Projects Reporter: Patrick McLean <chutzpah>
Component: PMS/EAPIAssignee: PMS/EAPI <pms>
Status: CONFIRMED ---    
Severity: normal CC: esigra
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 174380    

Description Patrick McLean gentoo-dev 2019-12-05 22:56:32 UTC
It would be useful to have a way to query various variables from eclasses, so the eclasses can do some sanity checking in the ebuild.

My initial suggestion is a way to query PROPERTIES and *DEPEND, a helper function would be more than sufficient.

For PROPERTIES it would be sometimes useful from an eclass to check if an ebuild is a live ebuild or not, which would allow some useful behaviour changes (for example the distutils-r1.eclass could get the versioning information for the installed python package from git metadata for live ebuilds).

For *DEPEND, I suggest "in_depstring <string> <atom>" to see if an atom is in the merged dependency string for an ebuild.

One recent example of where this might be useful (once again in distutils-r1.eclass). In distutils-r1_python_prepare_all (like src_prepare) we could do this:

if grep -E -q "(import .*setuptools|from setuptools import)" \
        && ! in_depstring BDEPEND 'dev-python/setuptools'; then
    die "Package's uses setuptools, but setuptools not in BDEPEND"
Comment 1 Ulrich Müller gentoo-dev 2020-10-25 17:58:09 UTC
1. USE-conditional expressions in *DEPEND etc. should be evaluated, I suppose?
2. How would groups like "|| ( )" be handled?
3. How exactly should dependency specifications be matched? For example, if the ebuild has >=dev-python/setuptools-50.3.0 in *DEPEND, would dev-python/setuptools match (and vice versa)?
4. Should slot dependencies and USE dependencies be included in the matching?

TBH, I'd rather see a proof-of-concept implementation before we consider this for the next EAPI.