salt.states.pkg.installed does not take fromrepo into account with apt

[belak]

Description of Issue/Question

When using pkg.installed, it _only_ checks if the package is installed, not if the package was installed from the proper repo.

The expected behavior is that it would install the version from the proper repository, rather than just skipping it because it's already installed. Alternatively, if this is expected behavior, it would be nice for this quirk to be documented.

Setup

common.sls

debian_backports_repo:
  pkgrepo.managed:
    - name: deb http://http.debian.net/debian jessie-backports main

common_backport_packages:
  pkg.installed:
    - pkgs:
      - mosh
      - tmux
    - fromrepo: jessie-backports

Steps to Reproduce Issue

# Ensure tmux is removed
$ apt-get purge tmux

# Install tmux from the default repo
$ apt-get install tmux
Output removed

$ apt-cache policy tmux
tmux:
  Installed: 1.9-6
  Candidate: 1.9-6
  Version table:
     2.2-1~bpo8+1 0
        100 http://http.debian.net/debian/ jessie-backports/main amd64 Packages
 *** 1.9-6 0
        500 http://http.debian.net/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status
$ salt '*' state.apply common
hostname.example.com:
----------
          ID: debian_backports_repo
    Function: pkgrepo.managed
        Name: deb http://http.debian.net/debian jessie-backports main
      Result: True
     Comment: Package repo 'deb http://http.debian.net/debian jessie-backports main' already configured
     Started: 19:27:35.755725
    Duration: 63.273 ms
     Changes:   
----------
          ID: common_backport_packages
    Function: pkg.installed
      Result: True
     Comment: All specified packages are already installed
     Started: 19:27:36.492046
    Duration: 416.791 ms
     Changes:   

Summary for hostname.example.com
------------
Succeeded: 2
Failed:    0
------------
Total states run:     2
$ apt-cache policy tmux
tmux:
  Installed: 1.9-6
  Candidate: 1.9-6
  Version table:
     2.2-1~bpo8+1 0
        100 http://http.debian.net/debian/ jessie-backports/main amd64 Packages
 *** 1.9-6 0
        500 http://http.debian.net/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status

Note that after running the common state, it does not install from the proper repo. It seems to work fine if no packages are installed and it seems to work alright if using pkg.latest (though that changes the definition of what this is trying to do)

Versions Report

Salt Version:
           Salt: 2015.8.8.2

Dependency Versions:
         Jinja2: 2.7.3
       M2Crypto: Not Installed
           Mako: Not Installed
         PyYAML: 3.11
          PyZMQ: 14.4.0
         Python: 2.7.9 (default, Mar  1 2015, 12:57:24)
           RAET: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.5
           cffi: 0.8.6
       cherrypy: Not Installed
       dateutil: 2.2
          gitdb: 0.5.4
      gitpython: 0.3.2 RC1
          ioflo: Not Installed
        libgit2: Not Installed
        libnacl: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.2
   mysql-python: 1.2.3
      pycparser: 2.10
       pycrypto: 2.6.1
         pygit2: Not Installed
   python-gnupg: Not Installed
          smmap: 0.8.2
        timelib: Not Installed

System Versions:
           dist: debian 8.4 
        machine: x86_64
        release: 3.16.0-4-amd64
         system: debian 8

[babilen5]

I would not necessarily call this expected behaviour and it would be great if one could rely on salt to install the package from the repository one has passed explicitly. This requires a lot more logic on top of the "is installed" check that is currently being performed as it requires salt to check if the installed version is available in the requested repository.

And, even then, another repo could ship the same version, but I guess that it would be acceptable not to be able to detect that too.

[jfindlay]

@belak, thanks for reporting. I agree with @babilen. Even if a package has the same name and version, if you're trying to install it from a specific repo, there must be a reason for it and the state should verify that rather than ignorantly relying on such equivalence as the name and version.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[pkramme]

reopen, please

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[Reiner030]

still not fixed... what do you like for the 3rd anniversary in April ? ;)

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[ookull]

4 years passed, still not fixed

[Cookiiiies]

If someone come across and look at least for a workaround:
You can use "version: latest" together with "upgrade: True" - this will update an existing package to the latest backports package.

e.g.:

pkg-install-iptables:
  pkg:
    - installed
    - name: iptables
    - fromrepo: buster-backports
    - version: latest
    - upgrade: True