Portage doesn't unmask the packages correctly. Some packages get unmasked even if "~x86" is not given. This happens only to some packages. Portage 2.0.51.19 ACCEPT_KEYWORDS="x86" Simple example: content of package.keywords file: media-tv/mythtv ~x86 emerge -s mythtv tells: * media-tv/mythtv Latest version available: 0.18.1-r1 Latest version installed: 0.18.1-r1 ___________________________________________________ content of package.keywords file: media-tv/mythtv (!!! note the missing "~x86" !!!) emerge -s mythtv tells: * media-tv/mythtv Latest version available: 0.18.1-r1 Latest version installed: 0.18.1-r1 ______________________________________________ content of package.keywords file: #media-tv/mythtv emerge -s mythtv tells: * media-tv/mythtv Latest version available: 0.16 Latest version installed: 0.18.1-r1 Reproducible: Always Steps to Reproduce: 1.see description 2. 3.
from "man portage" package.keywords Per-package KEYWORDS. Useful for mixing unstable pack- ages in with a normally stable machine or vice versa. This will allow you to augment ACCEPT_KEYWORDS for a sin- gle package. Note: There are two special KEYWORDS to help out here: * Match any stable KEYWORD ~* Match any unstable KEYWORD Format: - comments begin with # - one DEPEND atom per line followed by additional KEYWORDS Notice the FORMAT line, one DEPEND atom followed by addition KEYWORDS. just a DEPEND with no keywords isn't a valid line. I'd think the parser could generate an 'invalid line at bla' error however.
for key in pkgdict.keys(): # default to ~arch if no specific keyword is given if not pkgdict[key]: mykeywordlist = [] if self.configdict["defaults"] and self.configdict["defaults"]. has_key("ACCEPT_KEYWORDS"): groups = self.configdict["defaults"]["ACCEPT_KEYWORDS"]. split() else: groups = [] for keyword in groups: if not keyword[0] in "~-": mykeywordlist.append("~"+keyword) pkgdict[key] = mykeywordlist cp = portage_dep.dep_getkey(key) if not self.pkeywordsdict.has_key(cp): self.pkeywordsdict[cp] = {} self.pkeywordsdict[cp][key] = pkgdict[key] is the offending code, either change the manpage so that the behavior ( obviously noticed due to the comment ), or have it spit out an error.
The code isn't offending, the docs are :P
that's because jstubbs changed it, the wanker this is a dupe but i dont remember the original bug #
I pulled the "defaults to ~arch" part? That was a mistake. My intention was to pull the invalid example and also to make it clear that package.keywords was for ACCEPT_KEYWORDS rather than KEYWORDS.
so make a decision and i'll update the docs accordingly :) if you just have ACCEPT_KEYWORDS="x86" in make.conf, then what does this mean: /etc/portage/package.keywords:dev-libs/eet does that mean you implicitly accept ~${ARCH} for dev-libs/eet ? or should that mean nothing (and perhaps even spit a warning) ?
The former. That's been the behaviour ever since package.keywords was implemented afaik and was documented up until recently so no use going and breaking many peoples systems for no reason.
umm, that behavior has never been documented ... i know because i wrote the manpage for it and ive asked varying questions about package.keywords behavior to make sure the docs matched i was always told that package.keywords augmented ACCEPT_KEYWORDS and never implied anything
I must have been confusing code comments with documentation then and you must have been utterly confused in general in comment #4 :P Still, I think the former is still the better. I believe the code was written that way with the assumption that 99% of users that use package.keywords are arch users that want some ~arch packages. Seems like a correct assumption to me.
updated manpage
