"KEYWORDS" is a bad name for what it is (PMS says: "Keywords are used to indicate levels of stability of a package on a respective architecture arch.") Trying to explain why and how "KEYWORDS" means this is rightly difficult. Exherbo uses "PLATFORMS". That seems like a better name. Reproducible: Always
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.
