This is probably related to bug 208708. Since portage-2.1.4.2, there are warnings about packages for which portage claims that they are masked, but they actually are not! As far as I can see, portage reports the status of the packages of the time when they had been installed. But for versions which have become stable (and so the corresponding entry was removed from /etc/portage/package.keywords or package.unmask) there is no reason to warn about a nonexistent mask...
Sorry, but you need to be a whole lot more specific about what's producing wrong masked warnings, such as, the real output you get.
We'd like to be able to use binary packages without the need to have the corresponding ebuilds available. We also want the masking behavior for binary packages and installed packages to be consistent whether or not the corresponding ebuilds are available. The above goals don't seem compatible with you're idea of how ebuild keywords should override installed package keywords. I'm open to suggestions but right now I think the best solution is for you is to use package.keywords as necessary to umask the packages that trigger warnings.
(In reply to comment #1) > Sorry, but you need to be a whole lot more specific I guess Zac did understand me, but anyway here is one example: At every emerge I get hundreds of warnings like - net-dialup/ppp-2.4.4-r13 (masked by: ~x86 keyword) although the package is stable since several months. (The reason is apparently that I had installed it at a time when it still *was* ~x86, and I removed the package from package.keywords after it had become stable, because I do not want to run bleeding edge ppp). (In reply to comment #2) > We'd like to be able to use binary packages without the need to have the > corresponding ebuilds available. This is reasonable. > We also want the masking behavior for binary packages and installed packages > to be consistent whether or not the corresponding ebuilds are available. But with this I do not agree: Why shouldn't the (usually more up-to-date) ebuild information not be able to override the (usually older) mask status of an installed/binary package? This happens also with e.g. dependency information (i.e. if an ebuild author realizes that something is needed at runtime and changes the dependency, the dependency will be pulled in with emerge -NDu world, even if the package was already installed; at least this was the case with previous versions of portage). > I'm open to suggestions My suggestion is to use the installed/binary information for packages without an ebuild, but to use the ebuild information if this is available. (If you do not like this approach - which is most compatible with the previous portage behavior - how about at least checking which file is newer and using the information of the newer data)? > now I think the best solution is for you is to use package.keywords as > necessary to umask the packages that trigger warnings. Which means that if somebody installed e.g. once kde-4 or texlive while it was hard-masked, he will be forced to stay bleeding edge for these packages forever unless he wants to see pages of warnings at every emerge command or until he recompiles all these packages once they have become testing/stable just to inform portage about the actual current state of the portage tree. (The alternative of just unmasking *particular* versions of packages is in general not a good idea, since this way it is easy to miss security relevant changes which in particular for hard-masked stuff is not always explicitly announced and not always just an -rxx step).
(In reply to comment #3) > But with this I do not agree: Why shouldn't the (usually more up-to-date) > ebuild information not be able to override the (usually older) mask status of > an installed/binary package? This happens also with e.g. dependency information > (i.e. if an ebuild author realizes that something is needed at runtime and > changes the dependency, the dependency will be pulled in with emerge -NDu > world, even if the package was already installed; at least this was the case > with previous versions of portage). Portage still does this but at this time it's just a workaround for dependency resolver deficiencies (like bug 1343) and ebuild maintainers changing dependencies of installed packages in troublesome ways (like changing QT3VERSIONS in qt3.eclass). Once these issues are solved it will be nice if we can rely exclusively on the dependencies from /var/db/pkg. I do have a tool that copies metadata from ebuilds but I'd prefer to avoid doing anything like that if possible. The tool is currently available here: http://dev.gentoo.org/~zmedico/portage/branches/2.1/bin/vdb-tools.py > My suggestion is to use the installed/binary information for packages without > an ebuild, but to use the ebuild information if this is available. > > (If you do not like this approach - which is most compatible with the previous > portage behavior - how about at least checking which file is newer and using > the information of the newer data)? I think a reasonable workaround for now is to simply ignore keyword masks for installed packages. We can assume that if the user accepted the keywords a merge time then they never want to be bothered again. Also, the keywords case seems like it is common enough that lots of people are likely to complain about warnings (for example, people who temporarily change ACCEPT_KEYWORDS to merge some packages and then change it back).
This is fixed in 2.1.4.3.
Same bug for portage-2.2_pre2. Changing summary and reopening. (In reply to comment #5) > This is fixed in 2.1.4.3. > And it's broken again in portage-2.2_pre2. E.g., on sparc, - media-fonts/font-bitstream-100dpi-1.0.0 (masked by: missing keyword)
(In reply to comment #6) > Same bug for portage-2.2_pre2. Changing summary and reopening. > > (In reply to comment #5) > > This is fixed in 2.1.4.3. > > > > And it's broken again in portage-2.2_pre2. This bug was fixed in /main/trunk r9330 and the fix was backported to /main/branches/2.1.2 in r9331. portage-2.2_pre2 is /main/trunk r9328 while portage-2.1.4.3 is /main/branches/2.1.2 r9331.
(In reply to comment #6) > And it's broken again in portage-2.2_pre2. Ebuilds for SVN versions of Portage are available in Eaedificāta Repository: http://www.ffta.host.sk/Eaedificata/
In prefix I get this, which I think is the same bug: !!! The following installed packages are masked: - sys-libs/zlib-1.2.3-r01.1 (masked by: ) - sys-apps/grep-2.5.1a-r1 (masked by: ) ... (entire system + world here) on an emerge -Dua world Portage 2.2.00.9375-prefix
(In reply to comment #9) > !!! The following installed packages are masked: > - sys-libs/zlib-1.2.3-r01.1 (masked by: ) That type of message means that your visible() and get_masking_status() functions inside pym/_emerge/__init__.py don't match eachother for some reason. I guess you can add some debug statements inside visible() to see where it's rejecting the package.
(In reply to comment #10) > That type of message means that your visible() and get_masking_status() > functions inside pym/_emerge/__init__.py don't match eachother for some reason. > I guess you can add some debug statements inside visible() to see where it's > rejecting the package. There was indeed a little misalignment, the masking messages are gone now, thanks!
FIXED.
