eix-diff often shows package changes that are not really happening. An example is [<] == kde-plasma/plasma-meta (5.12.5(5)@11.06.2018; (~)5.13.0(5)[1] -> 5.12.5(5)): Merge this to pull in all Plasm It happened that 5.13.0 was masked previously and the version was removed with the last sync (5.13.1 appeared, which is now masked, too). Current stable package is 5.12.5 and I have kde-plasma/plasma-meta in package.accept_keywords. With the removal of the 5.13.0 the package mask was also updated. Thus, eix-diff thinks that 5.13.0 was not masked previously.
This bug contains two aspects: 1. The state of package masks already *is* stored in the eix cache. However, the masking state of "old" packages is _intentionally_ overridden by the current configuration, because it is sane that eix-diff shows the difference *in the tree* with respect to the *current configuration*. Anyway, this means only that the "correct" display in your case would not be [M](~)5.13.0(5)[1] -> 5.12.5(5) but instead with the mask being "eliminated" by the current configuration, i.e. {M}(~)5.13.0(5)[1] -> 5.12.5(5) 2, In you particular case you do not even see {M}. This is indeed a bug, related to the fact that (as I assume) the mask was only in the profile/package.mask file of some overlay. Technically, the reason for this bug is that eix-update by mistake failed to apply these files correctly (because to apply them correctly in eix-update, the repository name must be a known data for the version, and eix-update mistakenly failed to fill this data before applying the mask). Aspect 2 of this bug is now fixed in the eix master on github (>=eix-0.33.4; currently eix-0.33.4_alpha20180629 in the mv overlay). Aspect 1 of the bug I consider as CANTFIX, since it is not possible to apply the current configuration to old packages and simultaneously to keep the original stability setting. (In theory, one could separate mask handling from other stability handling, but this would need a major internal restructuring of eix and would perhaps be even more confusing for the user: Then some profile changes [e.g. concerning system packages] would be reflected by eix-diff and others [like masks] not.)
(In reply to Martin Väth from comment #1) > 2, In you particular case you do not even see {M}. This is indeed a bug, > related to the fact that (as I assume) the mask was only in the > profile/package.mask file of some overlay. yes, it was from the kde overlay (added via layman with sync-plugin-portage enabled) > Aspect 1 of the bug I consider as CANTFIX, since it is not possible to apply > the current configuration to old packages and simultaneously to keep the > original stability setting. (In theory, one could separate mask handling > from other stability handling, but this would need a major internal > restructuring of eix and would perhaps be even more confusing for the user: > Then some profile changes [e.g. concerning system packages] would be > reflected by eix-diff and others [like masks] not.) Logically, I would think that one should separate configuration changes caused by repo-differences (e.g., changes in package.mask in /usr/portage/profile) and user changes (e.g. changes in /etc/portage/package.unmask) rather than separating different configuration types. However, I do understand, that this is hard to distinguish with multiple levels of configurations provided in gentoo. Thus, I can understand if that is not fixed.
> I would think that one should separate configuration changes > caused by repo-differences [...] and user changes [...]. This is what is happening: The data stored in the cache-file corresponds to that of the repositories (only). Then the current configuration (incl. user changes) is applied to old and new versions. The latter is necessary also for old versions, because e.g. if you have a file in /etc/portage/package.unmask you would otherwise falsely be informed at _every_ sync that you can upgrade to the now-unmasked version. The problem is that there is not enough information available to apply the current user changes to the *old* repository configuration, because the old repository configuration data is not stored in the cache-file (only the masking/stability state *after* it has been applied is available, but this contains less information).
