Open absmith82 opened 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.
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.
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.
Do you have any other (probably better) solution then what a proposed in my previous message?
When running zabbix.pgsql.conf.sls on ubuntu 18.04 I get this error.
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.