Currently portage does not offer any clean way to inherit a profile from profile located in another repo (overlay or portage itself) = when you don't know the relative path. Since now every repository has a name the proposed solution is to add support for syntax like: ${portage}/profiles/foo/bar in parent file in profiles.
Maybe it would be a little clearer if we borrowed bash's associative array syntax, so you'd use something like "${repo[gentoo]}/profiles/foo/bar".
(In reply to comment #1) > Maybe it would be a little clearer if we borrowed bash's associative array > syntax, so you'd use something like "${repo[gentoo]}/profiles/foo/bar". This is pretty far outside of PMS... regardless of the proposal, any such syntax/changes are going to _have_ to have some form of marker in the repository that can be used to detect it's not a PMS compliant repo. As for syntax, parsing that is going to be ugly...
Well... It's designed for unofficial repositories supplying own profiles, not for portage or normal overlays so I hope it shouldn't cause any problems. It would be nice if we could get it official later so other package managers would support it too. But as I said I think I can live with it being unofficial.
(In reply to comment #3) > Well... It's designed for unofficial repositories supplying own profiles, not > for portage or normal overlays so I hope it shouldn't cause any problems. > > It would be nice if we could get it official later so other package managers > would support it too. But as I said I think I can live with it being > unofficial. The problem is that for all intents and purposes, it *is* an official repository when a PM looks at it- that is until it encounters incompatibilities like this, than it goes boom. It's the same reason ebuilds have EAPI- so that the PM knows up front if it supports the data or not. In this case, if what y'all are suggesting were added, there isn't a way to detect that it's a non PMS repo- offical or not, it's basically extending the format in an incompatible way, with the incompatibility not easily detected. So... add a marker that makes it easy to spot, and those issues mostly go away.
(In reply to comment #4) > So... add a marker that makes it easy to spot, and those issues mostly go away. We could start using metadata/layout.conf for markers like this.
*** This bug has been marked as a duplicate of bug 414961 ***
