Hello, I like the new autounmask function. Unfortunaley I do not agree with the default action that a new package is unmasked with >=foo/bar. This behaviour changed with this commit: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a531c670849d81edd15ba3e3ae820cbfe063db68 As I understand it the author is talking about use-flags that are changing: "Rational is that it's more likely that newer versions [...] will work with the same configuration changes [...]". If autounmask changes USE flags I agree with this idea, but if I want to unmask a particular version of a package I do *not* want to get every new unstable version installed by default. Example: emerge =app-office/libreoffice-bin-3.4.2 leads to: +>=app-office/libreoffice-bin-3.4.2 ~amd64 but I only want: +=app-office/libreoffice-bin-3.4.2 ~amd64 as I do not want to get an complete unstable/testing system (which would happen if I unmask with >= behaviour). In summary: >= is good for USE-flags, but not for unmasking Maybe it would possible to add a switch in /etc/make.conf? Or do I misunderstand the intention of this patch? Thank you Tobias Kaminsky Reproducible: Always
(In reply to comment #0) > As I understand it the author is talking about use-flags that are changing: > "Rational is that it's more likely that newer versions [...] will work with the > same configuration changes [...]". > If autounmask changes USE flags I agree with this idea, but if I want to unmask > a particular version of a package I do *not* want to get every new unstable > version installed by default. This applys for all types of configuration changes, including keywords. The problem is that both ways (using '=' or using '>=') have their pros and cons. It really deps on what you try to do. Maybe we really need a way to customize which type of atom to choose. On the other hand choosing a good default is important too. Maybe we should go with what the reporter says and let it always use '>=' for license+use and use '=' by default for keywords+mask and add an option to switch the latter to '>='.
My vote would be to use ~ instead. This has the advantage of not getting unstable updates indefinitely, while still allowing for specific bugfixing with -r1 bumps.
came looking to add this as a bug. totally agree with "Sebastian Luther (few)"
It's fixed in git so that the existing behavior is triggered by --autounmask-unrestricted-atoms, and by default it uses the '=' operator instead: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=7e956a6ec65b9b48a9fca3e928e7c7b56fd066b6
*** Bug 374331 has been marked as a duplicate of this bug. ***
*** Bug 372405 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > It's fixed in git so that the existing behavior is triggered by > --autounmask-unrestricted-atoms, and by default it uses the '=' operator > instead: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=7e956a6ec65b9b48a9fca3e928e7c7b56fd066b6 Is this handled in the same way for package.keywords and package.use? I mean, personally, I prefer to use "=" for package.keywords (as I want to try to use only stable as much as possible) but not for package.use (as USE changes are usually needed for any upcoming version and, anyway, if no longer available, it doesn't cause any problem
Yes, it's the same for all.
But I think that in bug 374331 we mostly agree on "=" being too restrictive for package.use (not for unmask and others), but package.use should always behave without "=" Other option would be to simply let portage to add that package.use entries... but I would need to find an easy way to clean cruft from package.use in the future ;)
(In reply to comment #9) > But I think that in bug 374331 we mostly agree on "=" being too restrictive for > package.use (not for unmask and others), but package.use should always behave > without "=" Now license and USE changes always use less restrictive atoms: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5f3826d1b1a82f4e0b2c2ffdb663e8b785d7e7fa
Thanks a lot :D
This is fixed in 2.1.10.20 and 2.2.0_alpha60.