Portage Error/Improper Behaviour Reproducible: Always Steps to Reproduce: 1.Use the No-Multilib profile 2.emerge virtualbox 3. Actual Results: [ebuild N #] app-emulation/virtualbox-4.2.10 USE="additions alsa opengl pam qt4 sdk -doc -extensions -headless -java -pulseaudio -python -vboxwebsrv -vnc" Expected Results: Should have seen the virtualbox-4.1.24 package and dependencies If a package is profile masked, portage should say Package Masked, list reason as entered then show what's need to meet the requirement. Otherwise it's behaving wrong as it should never show the ~arch unless user is on the ~arch branch as I am not. Forum Discussion about the issue http://forums.gentoo.org/viewtopic-p-7276768.html#7276768
You could read the full output: # emerge -vp app-emulation/virtualbox These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ~] app-emulation/virtualbox-additions-4.2.10 56,058 kB [ebuild N ] sys-power/iasl-20090123 USE="{-test}" 906 kB [ebuild N ~] dev-util/kbuild-0.1.9998_pre20120806 0 kB [ebuild N ~] app-emulation/virtualbox-modules-4.2.10 USE="-pax_kernel" 0 kB [ebuild N #] app-emulation/virtualbox-4.2.10 USE="additions alsa opengl pam pulsea udio python qt4 sdk -doc -extensions -headless -java -vboxwebsrv -vnc" 74,609 kB Total: 5 packages (5 new), Size of downloads: 131,572 kB The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by app-emulation/virtualbox-4.2.10[additions] # required by app-emulation/virtualbox (argument) =app-emulation/virtualbox-additions-4.2.10 ~amd64 # required by app-emulation/virtualbox-4.2.10 # required by app-emulation/virtualbox (argument) =dev-util/kbuild-0.1.9998_pre20120806 ~amd64 # required by app-emulation/virtualbox-4.2.10 # required by app-emulation/virtualbox (argument) =app-emulation/virtualbox-modules-4.2.10 ~amd64 # required by app-emulation/virtualbox (argument) =app-emulation/virtualbox-4.2.10 ~amd64 The following mask changes are necessary to proceed: (see "package.unmask" in the portage(5) man page for more details) # required by app-emulation/virtualbox (argument) # /world/gentoo/portage/profiles/features/64bit-native/package.mask: # AMD64 Team <amd64@gentoo.org> # Mask packages that rely on amd64 multilib =app-emulation/virtualbox-4.2.10 NOTE: The --autounmask-keep-masks option will prevent emerge from creating package.unmask or ** keyword changes. Notice that is says "would be merged". Which means the packages won't be. After the list of packages that "would be merged", the output goes on to explain what needs to be changed to install those packages. (In this case, you can't really accomplish those changes since you can't currently switch from no-multilib to multilib.) So what would need to change? Just the [ebuild *] bit (where the '#' already denotes that the package in question is masked)?
The documentation for the _autounmask_levels function is as follows: 0. USE 1. USE + license 2. USE + ~arch + license 3. USE + ~arch + license + missing keywords 4. USE + ~arch + license + masks 5. USE + ~arch + license + missing keywords + masks Some thoughts: * Do least invasive changes first. * Try unmasking alone before unmasking + missing keywords to avoid -9999 versions if possible Given that, it seems like you want a level it unmasks package.mask and doesn't accept ~arch keywords. I guess we could put the new level between 3 and 4, since 4 is currenty the first one unmasks package.mask.
Bug is the failure to inform user "Package Masked" for what ever reason. I shouldn't have to spend half the day getting confirmation in the forums that I am correct that due to no-multilib profile, a package has been masked as that profile.mask is controled by portage not the user. simply put, portage should never fail to post a Package.Mask message when a package has been masked for what ever reason as it shouldn't bother a user as that issue is covered. Possible reasons given are a package isn't stable on the arch, trying to mix stable and testing packages. We see often enough to not be suprised with a "WTF!!" moment as this caused.
(In reply to comment #3) > simply put, portage > should never fail to post a Package.Mask message when a package has been > masked for what ever reason as it shouldn't bother a user as that issue is > covered. My understanding is that it _did_ "post a Package.Mask message", as shown in comment #1: > The following mask changes are necessary to proceed: > (see "package.unmask" in the portage(5) man page for more details) > # required by app-emulation/virtualbox (argument) > # /world/gentoo/portage/profiles/features/64bit-native/package.mask: > # AMD64 Team <amd64@gentoo.org> > # Mask packages that rely on amd64 multilib > =app-emulation/virtualbox-4.2.10 As discussed in comment #2, my plan is to change the above message so that it tries to unmask virtualbox-4.1.24 instead of virtualbox-4.2.10. I thought that's what you wanted from what you said in comment #0: > Expected Results: > Should have seen the virtualbox-4.1.24 package and dependencies > > If a package is profile masked, portage should say Package Masked, list > reason as entered then show what's need to meet the requirement. Otherwise > it's behaving wrong as it should never show the ~arch unless user is on the > ~arch branch as I am not.
(In reply to comment #4) > > The following mask changes are necessary to proceed: > > (see "package.unmask" in the portage(5) man page for more details) > > # required by app-emulation/virtualbox (argument) > > # /world/gentoo/portage/profiles/features/64bit-native/package.mask: > > # AMD64 Team <amd64@gentoo.org> > > # Mask packages that rely on amd64 multilib > > =app-emulation/virtualbox-4.2.10 > > As discussed in comment #2, my plan is to change the above message so that > it tries to unmask virtualbox-4.1.24 instead of virtualbox-4.2.10. This should do it: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=566347ec232f50b07c8ab219fee4fef0788c3560
This is fixed in 2.1.11.59 and 2.2.0_alpha170.
Portage Error - Did not display the message "Package Masked by Profile" as it has for several packages I've looked at that are in ~amd64 as I'm on amd64 stable. What is so hard to understand that Portage never displayed the "Package Masked" message as it should have. That's the bug. Automask and such messages at the end have absolutely nothing to do with the problem of Portage not showing the Package Masked message as it should because the bloddy package is masked in the profile mask. The is absolutely no reason that portage should fail to display the package mask message when a package is actually masked and that is what the problem is. Either the profile.mask isn't being parsed correctly or the entry for virtualbox is screwed up and disables showing the package.mask message. How many times will I have to repeat that the problem is the lack of a message "PACKAGE MASKED" as is displayed for every bloody masked package? As stated, portage should NEVER fail to display the package masked message when any package is masked.
I suspect that you may want to set something like this in make.conf: EMERGE_DEFAULT_OPTS="--autounmask-keep-masks=y" That will prevent emerge from trying to unmask package.mask entries in order to solve dependencies.
(In reply to comment #7) I don't see why you get so angry. Could you give a mock-up of what a message for a masked package should look like? (I.e. I assume that the issue you have is that the '#' and the package.mask entry being displayed is not clear enough for you.)
