Puppet

From the looks of that debug output, —nocolor (-n) should probably be added to eix’s command line options.

This new patch fixes the incorrect handling of the name and category parameters in the portage provider, and now it behaves consistently with the rest of the providers: the portage provider won’t accept any more slashes in the name parameter; in fact they’re ignored but now the category parameter is honored, so the search fails.

Although now the provider is correct from puppet’s point of view, from this point it won’t be possible to handle with puppet packages with the same name under different categories (this doesn’t mean you won’t be able to manage them individually, this just means you won’t be able to manage BOTH of them using puppet). So if you want to install for example dev-java/ant and app-vim/ant using puppet you’re currently out of luck. Take a look at ImprovedResourceIdentification for a description of the problem and a proposed solution.

Regarding the slot problem, I haven’t been able to reproduce it with eix 0.7.9. Maybe you’re using a different version of eix? If so, please open another bug report with the description of the problem, the versions of puppet and eix and assign it to me.

Sorry, I meant the overlay problem

Jorge, I don’t understand why your proposed solution is necessary. If the shorthand name ‘sudo’ is ambiguous, people should be required to specify e.g. ‘app-vim/sudo’, which is the proper name of the package. We don’t need compound keys because puppet doesn’t need to know that ‘app-vim/sudo’ is composed of two pieces of information—it doesn’t use either of them individually. I think the old design was correct; the implementation was just inconsistent.

Replying to [comment:5 rainhead]:

Jorge, I don’t understand why your proposed solution is necessary. If the shorthand name ‘sudo’ is ambiguous, people should be required to specify e.g. ‘app-vim/sudo’, which is the proper name of the package. We don’t need compound keys because puppet doesn’t need to know that ‘app-vim/sudo’ is composed of two pieces of information—it doesn’t use either of them individually.

No, you’re wrong here. From puppet’s point of view, sudo is the name of the package and app-vim is the category of the package, and puppet provides parameters for both of them, so puppet does use them individually. If we use app-vim/sudo as the name of the package and provide code in the provider to handle that we’re abusing the name parameter.

I think the old design was correct; the implementation was just inconsistent.

I guess Luke has the final say regarding this, but I don’t think the design was correct: the provider was changing the name specified in the manifest to the real name of the package, and subsequent calls to the provider failed because of this and ignorance of the category paramater.

So basically I think we have two choices: either keep the option of specifying category/name in the name parameter, this being inconsistent with the rest of the providers and puppet itself, or provide a proper implementation and try to improve puppet to handle those problems. The first one opens a dangerous path: what if every provider would interpret the parameters as they wanted instead of doing it as puppet expects? That’s why I prefer the second one.

BTW, my name is Jose :o)