Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 170165 - PMS TODO: KEYWORDS in eclass
Summary: PMS TODO: KEYWORDS in eclass
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: PMS/EAPI
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-09 20:01 UTC by Ciaran McCreesh
Modified: 2014-07-17 18:44 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ciaran McCreesh 2007-03-09 20:01:02 UTC
Discussion for PMS TODO: do we forbid KEYWORDS in eclasses?
Comment 1 Zac Medico gentoo-dev 2007-03-17 23:59:10 UTC
Section 7.2 lists KEYWORDS as a variable that is "accumulated across eclasses".  There is no such accumulation of the KEYWORDS variable for any version of portage that is currently available.  IUSE, DEPEND, RDEPEND, and PDEPEND are the only accumulated variables.
Comment 2 Kevin F. Quinn (RETIRED) gentoo-dev 2007-03-29 14:21:12 UTC
FWIW I think KEYWORDS should be forbidden in eclasses.  By definition, eclasses are used by multiple versions of a package, or by different packages, and KEYWORDS are supposed to be specific to a package & revision.  Indeed, given that all stable marking should be done by (or agreed by) the arch teams, I can't see how it can be put into eclasses.  I made this mistake once; used to have it in the myspell eclass, but moved it to the ebuilds exactly because KEYWORDs relate to a specific ebuild, not a class of them.

Violators include enlightenment, games-etmod/mods/q3mod/ut2k4mod, gtk-engines, iiimf, nxserver-1.3.2, nxserver, stardict and tetex eclasses.

Of these, nxserver* are marked deprecated.

I don't think that the setting in enlightenment can be justified - I doubt very much that the maintainers of apps using that eclass are members of all arch teams.  Similarly gtk-engines.

stardict is weird - it has a statement in the ebuilds saying that if the keywords are changed in the stardict ebuilds, it should be set to the same in the eclass (which is used by the dictionaries).  This just doesn't make sense, to me.

The rest are relatively small affairs, and I don't think it would hurt to require the related packages to set their keywords explicitly.
Comment 3 Ciaran McCreesh 2007-04-11 19:22:34 UTC
r132. Should be banned by policy, not the spec.