Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 777141 - www-client/google-chrome (and friends): multiple KEYWORDS
Summary: www-client/google-chrome (and friends): multiple KEYWORDS
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Chromium Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: multiple-KEYWORDS
  Show dependency tree
 
Reported: 2021-03-19 04:10 UTC by Sam James
Modified: 2021-03-19 18:28 UTC (History)
0 users

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

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-03-19 04:10:26 UTC 
Please drop the multiple KEYWORDS definitions as it confuses tools like ekeyword and NATTkA.

The same pattern seems to be used in www-client/google-chrome*, www-plugins/chrome-binary-plugins, www-client/opera*, www-client/microsoft-edge-dev.
Comment 1 Mike Gilbert gentoo-dev 2021-03-19 09:31:36 UTC 
The KEYWORDS in these builds never change. Why would you need to run nattka or ekeyword on them?
Comment 2 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-03-19 09:34:17 UTC 
(In reply to Mike Gilbert from comment #1)
> The KEYWORDS in these builds never change. Why would you need to run nattka
> or ekeyword on them?

There are (broadly) two sets of > 1 KEYWORDS lines in tree:
1) dev-ros/*

2) Chromium ebuilds.

If the Chromium project is never going to switch to the usual stabilisation workflow, and the QA team is happy, then I'm happy to have an exception for binary-only ebuilds or whatever (as I said on #gentoo-qa when sultan asked).
Comment 3 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-03-19 09:38:25 UTC 
(In reply to Sam James from comment #2)
> If the Chromium project is never going to switch to the usual stabilisation
> workflow, and the QA team is happy, then I'm happy to have an exception for
> binary-only ebuilds or whatever (as I said on #gentoo-qa when sultan asked).

... or preferably, if this is that static, just put it in the eclass.