This is a simple bug. There should be *no* files in any default/linux/* profiles. Release-specific settings should go under releases/10.0 instead. Simply remove default/linux/*/10.0/eapi and put one in releases/10.0 and you're done. The design was that no changes should be made under default, as they are supposed to be profiles which only do inheritance. Thanks
the 'eapi' files are not inherited.
(In reply to comment #1) > the 'eapi' files are not inherited. > Sorry, I should have been more clear. Too much multi-tasking. I added the eapi files to multiple locations. It is not very clear *where* they should be, exactly. I asked for help and never got anything back. It doesn't make much sense for there to be a 'default/linux/amd64/10.0/eapi' file, you are correct. This does need to be re-evaluated.
(In reply to comment #2) > I added the eapi files to multiple locations. darkside, mind taking this bug then? The fix seems simple enough.
@dev-portage: Are these eapi files inherited from parents? I know deprecated files aren't, so doublechecking.
(In reply to comment #4) > @dev-portage: Are these eapi files inherited from parents? I know deprecated > files aren't, so doublechecking. No, they're not inherited. This reason is that it would be too easy to accidentally bump the eapi on inheriting profiles and have people wondering what just happened.
(In reply to comment #0) > This is a simple bug. There should be *no* files in any default/linux/* > profiles. Release-specific settings should go under releases/10.0 instead. > Simply remove default/linux/*/10.0/eapi and put one in releases/10.0 and you're > done. As explained by Zac, we have to put both "eapi" and "deprecated" files inside them, and this layout never worked the way you wanted.
I'm not sure if this matters, but it's worth noting that even though eapi files are not 'inherited' in the usual sense, they still cause the entire profile stack to be rejected by a package manager that doesn't support any one of the eapis within the entire profile stack. So, you still get a somewhat inheritance-like benefit from this file, even though the eapi itself isn't inherited.
This is really PMS domain.
If we do change the inheritance behavior, it won't cause any compatibility issues with portage since current versions of portage will actually accept atoms from any eapi regardless of what the 'eapi' files happen to contain. The eapi file is currently only used to reject a profile which contains an unsupported eapi.
The way it is makes sense. See the original discussion; this was covered then.
(In reply to comment #10) > The way it is makes sense. See the original discussion; this was covered then. > I'm convinced in the light of recent discussions.
