Summary: | Portage lacks support for inheriting profile from profile from other repository | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Grzegorz Kulewski <grzegorz> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 2.2 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Grzegorz Kulewski
2010-08-08 20:05:39 UTC
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 *** |