saltstack-formulas / zabbix-formula

http://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html
Other
50 stars 121 forks source link

Virtual packages are depricated. #128

Open absmith82 opened 4 years ago

absmith82 commented 4 years ago

When running zabbix.pgsql.conf.sls on ubuntu 18.04 I get this error.

ID: pgsql_packages
    Function: pkg.installed
      Result: True
     Comment: All specified packages are already installed
     Started: 18:08:42.393597
    Duration: 746.815 ms
     Changes:   
    Warnings: The following package(s) are "virtual package" names: postgresql-
              client. These will no longer be supported as of the Fluorine
              release. Please update your SLS file(s) to use the actual package
              name.

These packages should be placed into the map.jinja file so that we can install the correct package for the environment.

it looks like the correct client for Ubuntu depends on the version of Ubuntu, so this may be hard to maintain, but currently 16.04 uses postgresql-client-9.5, 18.04 and 18.10 use postgresql-client-10, and 19.04 uses postgresql-client-11

I can see how this could be a constant and daunting task as each release of different OSes could have a different client, however if this is not going to be supported moving forward it needs to be fixed.

myii commented 4 years ago

@absmith82 The problem here is this formula is still using the old-style map.jinja. In the new method (see the template-formula or many other formulas like it), we can drill down all the way to osfingermap.yaml and then configuring per distro release is a snap.

hatifnatt commented 4 years ago

I definitely understand why Salt deprecate support of "virtual packages" but form the user point of view it brings new inconvenience. postgresql-client always pointing to latest available version in current OS installation, i.e. Debian 9 default is postgresql-client-9.6 Debian 10 default postgresql-client-11 but if you add official PostgreSQL repository postgresql-client-12 became new default in both Deb 9 and 10.

Even if we have osfingermap with explicitly defined packages for each OS variant this still will not be as agile as "virtuial package" which always pointing to right package.

Although this issue definitely can be solved as I mention above, we just need to populate osfingermap with something like

Debian-10:
  pgsql:
    pkgs:
      - postgresql-client-common-11
      - postgresql-client-11

Debian-9:
  pgsql:
    pkgs:
      - postgresql-client-common-9.6
      - postgresql-client-9.6

# etc...

After this new issue will arise - it's became mandatory to explicitly define version if user want to use not "OS default" package version, maybe this is not a problem at all, depending on the point of view.

absmith82 commented 4 years ago

The issue is that regardless of the fact that is was an easier system, I agree I wish it were back, all current supported and future versions of salt will not support keeping the virtual packages.

hatifnatt commented 4 years ago

Do you have any other (probably better) solution then what a proposed in my previous message?