Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Virtual packages are depricated. #128

Open
absmith82 opened this issue Oct 9, 2019 · 4 comments
Open

Virtual packages are depricated. #128

absmith82 opened this issue Oct 9, 2019 · 4 comments

Comments

@absmith82
Copy link
Contributor

absmith82 commented Oct 9, 2019

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
Copy link
Member

myii commented Oct 9, 2019

@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
Copy link
Collaborator

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
Copy link
Contributor Author

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants