I know this bug has been beaten to death but I believe I have an interesting test case. What I was trying to do was mask out current versions. I have openoffice-2.0.2 installed. I entered '>=app-office/openoffice-2.0.2-r1' in 'package.mask only to get the following output #emerge -pv openoffice These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] app-office/openoffice-2.0.1-r1 [2.0.2] USE="kde xml% -binfilter -eds -gnome -gtk -java -ldap -mozilla" 188,724 kB
So, what's the terrible bug here? Those UD letters? Definitely a dupe of something I don't care enough to search for.
Can you explain the problem a little more. I'm not sure if this is a duplicate of bug 48195 or what.
The bug I am thinking of is 13632, and it's TWO years old sage. It is not a particular bug per se but you will notice the upgrade/downgrade *issue* keeps reappearing. This is a fundamental issue with Portage upgrading functionality. Why worry about that 'UD'? Ever compile openoffice? I estimate if it downgrades then "upgrades" it should take about 16 hours. Not an issue at all. And no I don't want to test if that will happen. Did you notice it is not respecting my mask settings? It should do nothing? Not an issue at all. Since Zac Medico response is mature I will answer it. I noticed that openoffice-2.0.2 ebuild is no longer available. The versions of openoffice available are 2.0.1-r1, 2.0.2-r1, 2.0.2-r2. The various options I tried... 1) masking >app-office/openoffice-2.0.2, result... [ebuild UD] app-office/openoffice-2.0.1-r1 [2.0.2] 2) masking >app-office/openoffice-2.0.2-r1, result... [ebuild U ] app-office/openoffice-2.0.2-r1 [2.0.2] 3) masking >=app-office/openoffice-2.0.2-r1, result... [ebuild UD] app-office/openoffice-2.0.1-r1 [2.0.2] only 2) is behaving as expected. It seems 2.0.2 it is not being considered in the calculation. I believe this is an interesting test case for causing the upgrade/downgrade issue which does not involve dependencies. Enough info?
reopening for duping
stupid bugzilla
Actually it is a dupe of 48195, problem being that the resolver doesn't look at vdb at all for candidates. *** This bug has been marked as a duplicate of 48195 ***
> > I noticed that openoffice-2.0.2 ebuild is no longer available. > The versions of openoffice available are 2.0.1-r1, 2.0.2-r1, 2.0.2-r2. > > The various options I tried... > > 1) masking >app-office/openoffice-2.0.2, result... > [ebuild UD] app-office/openoffice-2.0.1-r1 [2.0.2] Masking anything > 2.0.2 leaves what available. 2.0.1-r1. So this is "correct" > > 2) masking >app-office/openoffice-2.0.2-r1, result... > [ebuild U ] app-office/openoffice-2.0.2-r1 [2.0.2] Masking anything greater than 2.0.2-r1 leaves 2.0.2-r1 itself available, and 2.0.1-r1. Since 2.0.2-r1 is greater, it is selected. Correct also > > 3) masking >=app-office/openoffice-2.0.2-r1, result... > [ebuild UD] app-office/openoffice-2.0.1-r1 [2.0.2] masking >=2.0.2-r1 leaves only 2.0.1-r1 available, so it is selected. The bug here being that "2.0.2" is also technically "available" because it's installed, but portage doesn't appear to consider it. However, this IS a dupe :0
