Salt: pkg.installed broken in Gentoo in 2018.3

[EvaSDK]

Description of Issue/Question

Setup

After dirty patching issue reported in #47079, I found myself still unable to highstate minions running Gentoo. It looks like pkg.list_pkgs output changed leading pkg.installed to think that package have failed to install while they are actually already installed.
The problem manifests in https://github.com/saltstack/salt/blob/develop/salt/states/pkg.py#L816 where cver is None because it cannot find a key with just the package name (category/package in Gentoo) as it is present but with the version appended (category/package-version in Gentoo).

Steps to Reproduce Issue

On a 2017.7 minion:

$ sudo salt-call --local pkg.list_pkgs
local:
    ----------
    app-accessibility/accerciser:
        3.22.0
    app-accessibility/at-spi2-atk:
        2.24.1
    app-accessibility/at-spi2-core:
        2.24.1
[...]

On a 2018.3 minion:

$ sudo salt-call --local pkg.list_pkgs
local:
    ----------
    app-admin/apg-2.3.0b-r5:
        2.3.0b-r5
    app-admin/eselect-1.4.11:
        1.4.11
    app-admin/lib_users-0.10:
        0.10
    app-admin/logrotate-3.13.0:
        3.13.0
[...]

[EvaSDK]

It looks like commit ba7d00f58ef10dd441dbc90ea1d92f28eb92d7d1 changed _cpv_to_cp to use portage.dep_getkey(cpv) instead of portage.versions.cpv_getkey(cpv) but this function according to its docstring needs an atom like this: =media-libs/test-3.0 while the function is provided with media-libs/test-3.0 which fails. I switched locally to portage.version.cpv_getkey(cpv) which seems to produce the expected behavior and could at least allow me to run states with pkg.installed.

[gtmanfred]

Can you open a PR to fix this and explain what you are fixing from https://github.com/saltstack/salt/pull/43345

And also ping @ribx in it to get his opinion since he wrote the code here?

https://docs.saltstack.com/en/latest/topics/development/contributing.html

It should be opened against the 2018.3 branch

Thanks,
Daniel

[ribx]

I changed this to the dep_getkey(), because the same function was used to parse portage files in /etc/portage which do include =.

Maybe we should always first try dep_getkey, which demands the format =sys-devel/binutils-2.29.1-r1, if it fails cpv_getkey and if that also fails the other hacks like _porttree().dbapi.xmatch('bestmatch-visible', p).

[EvaSDK]

I'd advocate for using functions that adequate to API output, in this case _vartree().dbapi.cpv_all() does not include =. It can be discussed with portage maintainers whether this makes sense or not compared to the rest of the API. I admit I'm not very fluent there.

[ribx]

I am also neither fluent with saltstack dev nor with portage internals.

There should be some tests to check these functions, I added some for the portage_config module. I did not catch this usage of _cpv_to_cp version, when I changed the code. Sorry for that.

[mgomersbach]

ribx is there any way I can help you with this?
What are your current difficulties?

[ribx]

Mostly spare time. Had to finish a project until my child is born. Now he is already its way.. I cannot tell you any date when I can look into this. Totally depends on him now (and the project will be late now anyway).

[mgomersbach]

First of all: Congratulations with your child!
I'll see if I can look into this tonight and make some suggestions

[ribx]

I just found the time to finally tackle the problem, and it looks like it was already fixed last year when it was reported:
https://github.com/saltstack/salt/commit/551f4e10cf928a5a478544bc30f04d2a6c506d1c
it is also in the 2018.3 branch. So, this can be closed @EvaSDK!

[EvaSDK]

Agreed, things appear to work fine now, thanks.