Summary: | [Future EAPI] Rename KEYWORDS → PLATFORMS | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Matt Turner <mattst88> |
Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | esigra, gentoo, pacho, sam, tanekliang |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174380 |
Description
Matt Turner
2022-09-14 15:51:50 UTC
Yeah, nobody ever understands KEYWORDS. It also leads to awkward explanations when trying to discuss visibility. It seems like a reasonable idea. If we are to introduce an incompatible change, then maybe we should also think about moving keywords into a separate file? Interspersed stabilisation commits make it harder to follow the change history of ebuilds, and they tend to cause merge conflicts. Moving them out of ebuilds would avoid both. (In reply to Ulrich Müller from comment #2) > If we are to introduce an incompatible change, then maybe we should also > think about moving keywords into a separate file? Interspersed stabilisation > commits make it harder to follow the change history of ebuilds, and they > tend to cause merge conflicts. Moving them out of ebuilds would avoid both. I'm not opposed to this in principle, but how would we then handle rekeywording? The separate file would contain multiple version entries? (In reply to Ulrich Müller from comment #2) > If we are to introduce an incompatible change, then maybe we should also > think about moving keywords into a separate file? Interspersed stabilisation > commits make it harder to follow the change history of ebuilds, and they > tend to cause merge conflicts. Moving them out of ebuilds would avoid both. Yes, I think this is an interesting idea -- I remember discussing it with kentnl. I'm not sure the precise details have been worked out, but it's definitely something I think we should think about. |