What’s new in sys-apps/portage-2.1.9? Here is the portage-2.1.9 section of the release notes:
- The emerge “world” set now includes separate “selected” and “system” sets, where the “selected” set includes packages listed in /var/lib/portage/world.
- Package set names in emerge arguments have to be prefixed with @ (exceptions: ‘world’ and ‘system’ can be used without the prefix).
- Configuration files now support atoms with wildcards inside the category and package name parts of the atoms. See the portage(5) man page for details.
- The functionality of the autounmask program is emulated by the new emerge –autounmask option, which outputs required configuration changes for package.accept_keywords and package.use.
- The new emerge –exclude option allows packages to be excluded from the dependency resolution. Doing so might result in a fatal error. See the emerge(1) man page for details.
- Per-package environment variables can be set with the new package.env configuration file in /etc/portage/. See the portage(5) man page for details.
- Support for per-package bashrc files in /etc/portage/env. See the portage(5) man page for details.
- The package.keywords configuration file in /etc/portage/ is now deprecated. Instead use the package.accept_keywords file which has the same format and behavior. See the portage(5) man page for details.
- FEATURES=”fixlafiles” (enabled by default): Rewrites newly installed .la files in the same way dev-util/lafilefixer does. Note that this won’t fix your installed .la files.
Good to hear!
Ha, is there any sense in having Portage 2.2 installed now? Looks like only @preserved-rebuild hasn’t been ported to 2.1. Yet.
thank you for the update, just a little thought :
*The functionality of the autounmask program is emulated by the new emerge –autounmask option, which outputs required configuration changes for package.keywords and package.use
#The package.keywords configuration file in /etc/portage/ is now deprecated. Instead use the package.accept_keywords file which has the same format and behavior. See the portage(5) man page for details.
One of this items could use a change 😉
@Nickolaj:
The only difference between portage 2.2 and 2.1.9 is that some features such as preserve-libs and set configuration are disabled in 2.1.9. These features are disabled by some constants that are shown in the following commit:
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=25ab3342cd24efee4d08ea816e04b0bed22a854c
@Mark:
Since bug #292083, profiles support both package.keywords and package.accept_keywords, which behave differently (as described in the portage(5) man page). Therefore, for consistency, the /etc/portage/package.keywords file is being deprecated since it behaves similarly to the package.accept_keywords that’s supported by profiles.
I see, thanks for clarification, Zac.
About Mark’s remark: I think he points out that Portage should output changes “for package.accept_keywords”, not package.keywords, since last filename is deprecated.
I like:
* Configuration files now support atoms with wildcards inside the category and package name parts of the atoms.
Means things like “dev-python/* examples” should work now in /etc/portage/package.use[/*]!
Bleah, I dislike the excessively long rename from p.keywords to p.accept_keywords. It’ll mean changing all our docs.
So, when 2.1.9 is ready to go stable, PLEASE make sure a documentation bug is opened, so that the GDP can work with you guys on updating all our stuff. Especially this sets thing, if it is fully implemented in a 2.1 release. IIRC we haven’t mentioned it yet because only hardmasked 2.2 versions offered sets support.
@Josh:
The docs don’t necessarily have to be updated right away with respect to these changes. People can continue to use package.keywords as usual, and they can also use continue to use ‘system’ and ‘world’ package sets as usual. With portage-2.1.9, no deprecation warnings are displayed for people sticking to old behaviors.
Also, portage-2.1.9 doesn’t support the package set configuration extensions that portage-2.2_rc has. In portage-2.1.9, the only difference from previous releases is the addition of the @selected set and support for using ‘@’ to distinguish @world, @system, and @selected from normal package atoms.
I’d suggest you also rename package.license for consistency then. And I agree with Josh, the new name sucks, though I see why you’re doing it with package.keywords having different semantics currently.
@Marius:
Hmm, renaming package.license seems like a good idea. However, given people’s resistance to change, I think I’d prefer to leave it as is for now. The renaming of package.keywords just seemed like a necessity, given the different meaning in profiles.