Summary: | sys-apps/portage-2.2_rc20 only accepts sets from last overlay | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Togge <togge.gentoo> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Togge
2008-12-30 08:37:11 UTC
That doesn't sound right, the code in question is processing all overlays in order. Please attach the relevant sets.conf files form the overlays involved, maybe they are overwriting each others set definitions. :::kde-testing::: [kde sets] class = portage.sets.files.StaticFileSet multiset = true directory = ${repository:kde}/sets/ :::kde-crazy::: [kde sets] class = portage.sets.files.StaticFileSet multiset = true directory = ${repository:kde-crazy}/sets/ Could it be because they both use "kde sets"? Yes, sets.conf sections that have the same name will override eachother. Those overlays should use different section names such as [kde testing] and [kde crazy]. Closing as upstream as the fault is not inportage but in the setup of the overlays. |