Since update from sys-apps/portage-2.1.10.44 to sys-apps/portage-2.1.10.49 INSTALL_MASK (as set from /etc/portage/bashrc and/or /etc/portage/env/$category/$package) is ignored and all contents of binary packages are getting merged. Note: I'm merging into a different root, e.g. ROOT=/path/to/image PORTAGE_CONFIGROOT=/path/to/image emerge --usepkg $pkg after having built the binary package. Reproducible: Always
Created attachment 306595 [details] emerge --info for 2.1.10.44 ROOT=/path/to/imgage PORTAGE_CONFIGROOT=/path/to/image emerge --info Generated with portage-2.1.10.44
Created attachment 306597 [details] emerge --info for 2.1.10.49 ROOT=/path/to/imgage PORTAGE_CONFIGROOT=/path/to/image emerge --info Generated with portage-2.1.10.49
It's related to PKG_INSTALL_MASK changes: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5d5364e982820fda56db5a40884e1c5f8e784b96 You should use make.conf or /etc/portage/package.env instead of bashrc. Something like this will work: echo "cat/pkg-atom install_mask.conf" >> /etc/portage/package.env echo "INSTALL_MASK=\"blah blah blah\"" > /etc/portage/env/install_mask.conf
(In reply to comment #3) > It's related to PKG_INSTALL_MASK changes: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=5d5364e982820fda56db5a40884e1c5f8e784b96 > > You should use make.conf or /etc/portage/package.env instead of bashrc. > Something like this will work: > > echo "cat/pkg-atom install_mask.conf" >> /etc/portage/package.env > echo "INSTALL_MASK=\"blah blah blah\"" > /etc/portage/env/install_mask.conf Why isn't /etc/portage/package.env implicit for /etc/portage/env/$cat/$pkg? Having to maintain a list of env override files like package.env is rather annoying. Using package.env work and surprisingly also causes bashrc to be implicitly read!
(In reply to comment #4) > Why isn't /etc/portage/package.env implicit for /etc/portage/env/$cat/$pkg? The format of package.env config files is like make.conf, which doesn't support the full bash syntax that /etc/portage/env/$cat/$pkg supports. > Having to maintain a list of env override files like package.env is rather > annoying. It has the advantage that you can refer to the same config file with multiple atoms, which is nice for code sharing. > Using package.env work and surprisingly also causes bashrc to be implicitly > read! That's because a package.env INSTALL_MASK setting triggers execution of the bash INSTALL_MASK code, and any relevant bashrc is sourced as a side effect. We could implement INSTALL_MASK using python alone, and then we won't have to execute bash in this case.
(In reply to comment #5) > (In reply to comment #4) > > Having to maintain a list of env override files like package.env is rather > > annoying. > > It has the advantage that you can refer to the same config file with > multiple atoms, which is nice for code sharing. That is also possible with env/$cat/$pkg using symlinks or hardlinks... An improvement though would be to consider env/$cat/$pkg.conf automatically as if they were mentioned in package.env (using the same rules for $pkg as for bashrc) > > Using package.env work and surprisingly also causes bashrc to be implicitly > > read! > > That's because a package.env INSTALL_MASK setting triggers execution of the > bash INSTALL_MASK code, and any relevant bashrc is sourced as a side effect. > We could implement INSTALL_MASK using python alone, and then we won't have > to execute bash in this case. Please adjust portage man page to explicitly state that /etc/portage/env/ is NOT considered for binary packages (unless sometimes implicitly loaded for some parsing task), the man page shipping with 2.1.10.49 does not state it. It just says package.env should be used for environ variables: | In this directory additional package-specific bashrc files can be created. | Note that if package-specific environment variable settings are all | that's needed, then /etc/portage/package.env should be used instead of the | bashrc approach that is described here.
(In reply to comment #6) > That is also possible with env/$cat/$pkg using symlinks or hardlinks... With package.env you can also set variables that are available during dependency resolution. For example, you can set FEATURES=test which will automatically enable USE=test and pull in dependencies that are conditional on this USE flag. It's not possible to do this with bashrc because it would slow down dependency calculation too much if we had to spawn a bunch of bash processes. > An improvement though would be to consider env/$cat/$pkg.conf automatically > as if they were mentioned in package.env (using the same rules for $pkg as > for bashrc) I think that would just be feature bloat, and the existing approach works well enough. > Please adjust portage man page to explicitly state that /etc/portage/env/ is > NOT considered for binary packages (unless sometimes implicitly loaded for > some parsing task), the man page shipping with 2.1.10.49 does not state it. It's not just binary packages. INSTALL_MASK won't work when building from source either, if you only set it in bashrc. I guess we should reference package.env from the INSTALL_MASK docs.
(In reply to comment #7) > (In reply to comment #6) > > That is also possible with env/$cat/$pkg using symlinks or hardlinks... > > With package.env you can also set variables that are available during > dependency resolution. For example, you can set FEATURES=test which will > automatically enable USE=test and pull in dependencies that are conditional > on this USE flag. It's not possible to do this with bashrc because it would > slow down dependency calculation too much if we had to spawn a bunch of bash > processes. You dropped&missed the context, though thanks for the information! I was referring to code sharing between atoms. Will portage always support syntax like INSTALL_MASK="${INSTALL_MASK} ..." in files referred from package.env (and allow line breaks between the quotes)? Otherwise code-sharing (as in extending the contents of variable) becomes difficult. At least currently VAR+="..." does not work. For code-sharing I'm now doing: package.env: $cat/$pkg INSTALL_MASK.conf $cat/$pkg.conf where $cat/$pkg.conf adds files to the base INSTALL_MASK defined in INSTALL_MASK.conf > > An improvement though would be to consider env/$cat/$pkg.conf automatically > > as if they were mentioned in package.env (using the same rules for $pkg as > > for bashrc) > > I think that would just be feature bloat, and the existing approach works > well enough. Unfortunate, as maintaining two files (when removing one, one has to think dropping the reference from package.env - though portage will remind to -- but when adding it has no effect if one did forget to update package.env) > > Please adjust portage man page to explicitly state that /etc/portage/env/ is > > NOT considered for binary packages (unless sometimes implicitly loaded for > > some parsing task), the man page shipping with 2.1.10.49 does not state it. > > It's not just binary packages. INSTALL_MASK won't work when building from > source either, if you only set it in bashrc. I guess we should reference > package.env from the INSTALL_MASK docs. Don't forget mentioning for bashrc and env/ that make.conf variables are not supposed to be set there and will not [always] work [as one might expected]. An einfo in portage's pkg_postinst() might be useful as well, as Internet is full of suggestions for INSTALL_MASK in bashrc!
(In reply to comment #8) > Will portage always support syntax like INSTALL_MASK="${INSTALL_MASK} ..." > in files referred from package.env (and allow line breaks between the > quotes)? Otherwise code-sharing (as in extending the contents of variable) > becomes difficult. At least currently VAR+="..." does not work. Yes, that's part of the make.conf format. It will continue to support everything it supports now, in order to remain backward compatible. > Don't forget mentioning for bashrc and env/ that make.conf variables are not > supposed to be set there and will not [always] work [as one might expected]. It already says in `man 5 portage`: "Note that if package-specific environment variable settings are all that's needed, then /etc/portage/package.env should be used instead of the bashrc approach that is described here." There are only a few variables like INSTALL_MASK that specifically need to go in package.env. So, in the bashrc docs, I can explicitly mention specific variables like INSTALL_MASK and FEATURES that really shouldn't be set in bashrc. > An einfo in portage's pkg_postinst() might be useful as well, as Internet is > full of suggestions for INSTALL_MASK in bashrc! Yeah, I guess I could trigger a message like that when upgrading from <sys-apps/portage-2.1.10.49.
I've updated the bashrc documentation with a note about special variables: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5dbea626d2305625b1562eebfde4fe7b4ee601d9 I didn't add anything to the make.conf.5 INSTALL_MASK docs because it already has the following at the top of make.conf.5: "In order to create per-package environment settings, refer to package.env in portage(5)."
This is fixed in 2.1.10.53 and 2.2.0_alpha97.
