Summary: | sys-apps/portage-2.1.10.65 omits some variables from cascaded profiles make.defaults | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Ed Wildgoose <gentoo> |
Component: | Core - Configuration | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 414961 | ||
Bug Blocks: |
Description
Ed Wildgoose
2012-07-30 16:51:44 UTC
Due to bug #414961, PORTDIR and PORTDIR_OVERLAY are evaluated prior to the profile, which makes it possible for profiles to reference repositories. USE_EXPAND variables like NGINX_MODULES_HTTP and XTABLES_ADDONS are special. They behave like incremental variables, but don't support negative seeings. If you want full incremental control, you can modify them via the corresponding USE flags. For example, USE="-xtables_addons_*" can be used to discard inherited XTABLES_ADDONS flags. Thanks for the feedback. I'm not sure I understand the final conclusion - how do I set PORTDIR_OVERLAY from a local profile? If it's possible with some later version of portage it would be interesting to know? If it's not possible and will not be possible in the future, then workarounds would be appreciated (profile/bashrc?) With regards to the other variables, that makes a lot of sense, thanks. For the benefit of google, the variables which are subject to use_expand are listed in /usr/portage/profiles/desc/ see: http://devmanual.gentoo.org/general-concepts/use-flags/index.html Can you confirm therefore that in a profile one should apply non incremental flags with something like: USE="-xtables_addons_*" XTABLES_ADDONS="something" Thanks (In reply to comment #2) > Thanks for the feedback. I'm not sure I understand the final conclusion - > how do I set PORTDIR_OVERLAY from a local profile? You can't. > If it's possible with > some later version of portage it would be interesting to know? I wasn't planning to support that, because the behavior from bug 414961 means that the repository configuration needs to be loaded before the profile. > If it's not > possible and will not be possible in the future, then workarounds would be > appreciated (profile/bashrc?) Maybe you have have make.conf source the file from your profile which contains PORTDIR_OVERLAY. The make.conf source command is similar to a shell like bash. > With regards to the other variables, that makes a lot of sense, thanks. For > the benefit of google, the variables which are subject to use_expand are > listed in /usr/portage/profiles/desc/ > see: http://devmanual.gentoo.org/general-concepts/use-flags/index.html > > Can you confirm therefore that in a profile one should apply non incremental > flags with something like: > USE="-xtables_addons_*" > XTABLES_ADDONS="something" You'll probably have to do it more like this: USE="-xtables_addons_* xtables_addons_something" Hmm, this doesn't seem to leave me a satisfactory solution here. I picked a bad example in my original post, in fact I don't think any of my vserver machines have anything in /etc/make.conf, except the "PORTAGE_ELOG_MAILFROM" line (would like to get rid of that also..), I maintain everything in profiles at present. To have to add a line to every make.conf on 30 odd virtual machines is kind of annoying Having /etc/make.conf source some file in /etc/make.profile is also not cool because either you need to add some logic to go searching up the profile to find the inherited file, or duplicate this file in every profile.. I'm not sure I understand how bug 414961 actually affects this anyway. Are you saying that ":" now will search relative to both "PORTDIR/profiles" *and* "PORTDIR_OVERLAY/profiles"? If not the latter, then why does this change affect the overlay variable? At the very least could we default PORTDIR_OVERLAY=/usr/local/portage ? Thanks (In reply to comment #4) > I'm not sure I understand how bug 414961 actually affects this anyway. Are > you saying that ":" now will search relative to both "PORTDIR/profiles" > *and* "PORTDIR_OVERLAY/profiles"? If not the latter, then why does this > change affect the overlay variable? The extension from bug 414961 allows profiles to reference profiles from other repositories. For example, you can have a profile in an overlay that inherits from the gentoo:targets/desktop profile. > At the very least could we default PORTDIR_OVERLAY=/usr/local/portage ? That would result in warning messages if /usr/local/portage doesn't exist. |