Paludis does not pretend to get the latest version of package, if all packages are masked

[jmacdonagh]

If all packages in the tree are masked, then Paludis will --pretend to get the earliest version. Here is an example:

I wanted to install monodevelop. There are four versions in the tree, 0.10, 0.12, 0.14, and 0.15. I didn't want to unmask all versions of monodeveop, only the 0.15 release. I did:

paludis --pretend --install monodevelop

It successfully told me that monodevelop was masked, but towards the bottom of the output, where it shows the actual packages that would have been installed, it showed that it was trying against 0.10.

I added ~x86 to the keywords file for monodevelop, ran the same command, and got output showing that dependencies for monodevelop were masked. In this case, it showed that it was trying to install 0.15.

So, the issue seems to be that Paludis will not try to install the latest masked version of a package, if all versions are masked. If, say, version 0.01 was available and not masked, I understand that it would try to do that, but if all are masked, it should try to do the latest masked version.

The only real issue this brings is that if I wanted to unmask monodevelop, but only wanted to unmask the latest version, I would have thought it was 0.10 rather than 0.15.

[ciaranm]

It's *supposed* to try to get the best of all versions that require the lowest degree of unmasking. What does paludis --query moodevelop show (before you modify your keywords file)?

[jmacdonagh]

Let me try and re-explain the issue.

Paludis has a feature where it will show you all the packages that are masked when you try to merge something (as opposed to portage which shows one package at a time).

So, before I had made any changes to my keyword file, I tried paludis --pretend --install monodevelop. It told me that it was masked, but at the bottom it showed output similar to this (sorry, I don't have access to the machine now so the output won't really match what it did):

monodevelop-0.10 masked by ~amd64

but I expected it to show:

monodevelop-0.15 masked by ~amd64

Keep in mind all monodevelop packages were masked. So, when I did the command without changing the keywords file, it *should* have tried to install monodevelop-0.15, because that was the newest build that required the least amount of unmasking.

Now, when I added:

monodevelop *

into my keywords file, and ran paludis --pretend --install monodevelop, it showed:

monodevelop-0.15

You should be able to reproduce the error (provided that you don't use monodevelop yourself ;) )

[jmacdonagh]

Sorry, here's the info you asked for:

Before changing my keywords.conf file:

# paludis -ip monodevelop

• dev-util/monodevelop [N 0.10] <target>

# paludis --query monodevelop

• dev-util/monodevelop

gentoo: (0.10)K (0.12)K (0.14)K (0.15)K* {:0} Homepage:  http://www.monodevelop.com/ Description: Integrated Development Environemnt for .NET Relevant USE flags: -aspnet -aspnetedit -boo firefox java -seamonkey subversion Masked by keywords: ~amd64 ~x86

Then, I added to keywords.conf: dev-dotnet/ikvm-bin * dev-dotnet/gtksourceview-sharp * dev-util/monodevelop *

and: # paludis -ip monodevelop

• dev-util/monodevelop [N 0.15] <target>

# paludis --query monodevelop

• dev-util/monodevelop

gentoo: 0.10 0.12 0.14 0.15* {:0} Homepage:  http://www.monodevelop.com/ Description: Integrated Development Environemnt for .NET Relevant USE flags: -aspnet -aspnetedit -boo firefox java -seamonkey subversion

[jmacdonagh]

Well, that didn't seem to come across as nicely as I had hoped. But as you can see, before changing keywords.conf, it was talking about installing 0.10 (which is masked). After unmasking all monodevelops, it correctly tries to install 0.15

[ciaranm]

Oh, I see how that can happen. I have a new resolver locally that does this a bit differently -- it builds up the dep list in stages rather than all at once, so it can usually catch what's going on here. (It's not as simple as Paludis not taking the best package in this particular case.)

[ciaranm]

The new resolver gets this right. It won't be fixed in the legacy resolver.