[opensuse-factory] Advise needed on update-alternatives
Hi, we had some days ago a discussion on how to prevent postgres10 installation, as postgres96 is required: https://lists.opensuse.org/opensuse-factory/2018-06/msg00033.html The solution at that time, adding conflicts for postgres10, worked, but broke the openQA testing. So I went for adding update-alternatives --set postgresql /usr/lib/postgresql96 to the post-section of the spec-file This is objected by the maintenance team, see http://bugzilla.opensuse.org/show_bug.cgi?id=1096706 as '...consumer packages should be allowed to change the alternative selection for another package just so they can deal with them.' An idea would be to call postgres96 directly, but that is not an alternative, as the package just calls uri = postgresql://username:password@host:port/ and listens to what comes back. [setting up a different port for postgres96 is an expert solution that I would not consider here] As we have some more packages that cant deal with postgres10 (akonadi...) I feel that setting update-alternatives to postgres96 is a viable solution. Please share your opinion Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sonntag, 17. Juni 2018 17:08:40 CEST Axel Braun wrote:
Hi,
we had some days ago a discussion on how to prevent postgres10 installation, as postgres96 is required: [...]
I think you are trying to solve the problem on the wrong level. Obviously, GH needs postgres in version 9.6, but how this requirement is met is out of scope for RPM. You can run PG as a local instance on a random, local port. You can run PG on a remote server or in a container on the same host. Using update-alternatives is IMHO not an option, as it would change the system default, but still does not guarantee which database version will be used, e.g. if not running on the local host. Probably, you should add a dependency on a metapackage, and provide different variants for this dependency: - one package configuring GH to use a remote PG instance - one package configuring GH to use a local PG instance, running on a randomized local port. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Hello Stefan, Am Sonntag, 17. Juni 2018, 17:39:00 CEST schrieb Stefan Brüns:
On Sonntag, 17. Juni 2018 17:08:40 CEST Axel Braun wrote:
Hi,
we had some days ago a discussion on how to prevent postgres10 installation, as postgres96 is required: [...]
I think you are trying to solve the problem on the wrong level. Obviously, GH needs postgres in version 9.6, but how this requirement is met is out of scope for RPM. You can run PG as a local instance on a random, local port. You can run PG on a remote server or in a container on the same host.
Using update-alternatives is IMHO not an option, as it would change the system default, but still does not guarantee which database version will be used, e.g. if not running on the local host.
Both of your points above are true, but I would consider this as 'expert option' - they know what to do anyway. The target is to have a system up and running after the installation, with only minor interaction needed, and without the need to read a postgres-book beforehand. This was all achieved out of a single package, but not anymore with postgres10 as default.
Probably, you should add a dependency on a metapackage, and provide different variants for this dependency: - one package configuring GH to use a remote PG instance - one package configuring GH to use a local PG instance, running on a randomized local port.
Do you maybe have an example? Thanks for your input Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday, 18 June 2018 09:19:18 CEST Axel Braun wrote:
Hello Stefan,
Am Sonntag, 17. Juni 2018, 17:39:00 CEST schrieb Stefan Brüns:
On Sonntag, 17. Juni 2018 17:08:40 CEST Axel Braun wrote:
Hi,
we had some days ago a discussion on how to prevent postgres10 installation,
as postgres96 is required: [...]
I think you are trying to solve the problem on the wrong level. Obviously, GH needs postgres in version 9.6, but how this requirement is met is out of scope for RPM. You can run PG as a local instance on a random, local port. You can run PG on a remote server or in a container on the same host.
Using update-alternatives is IMHO not an option, as it would change the system default, but still does not guarantee which database version will be used, e.g. if not running on the local host.
Both of your points above are true, but I would consider this as 'expert option' - they know what to do anyway. The target is to have a system up and running after the installation, with only minor interaction needed, and without the need to read a postgres-book beforehand.
This was all achieved out of a single package, but not anymore with postgres10 as default.
Probably, you should add a dependency on a metapackage, and provide different variants for this dependency: - one package configuring GH to use a remote PG instance - one package configuring GH to use a local PG instance, running on a randomized local port.
Do you maybe have an example?
I know of https://github.com/os-autoinst/openQA/blob/master/openQA.spec#L178 providing a local database for openQA for the most simple case of a single- user local setup. So a user can install this helper package. For any expert setup do not install the package and configure the database on your own -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Oliver, Am Dienstag, 19. Juni 2018, 16:17:58 CEST schrieb Oliver Kurz:
On Monday, 18 June 2018 09:19:18 CEST Axel Braun wrote:
Hello Stefan,
Am Sonntag, 17. Juni 2018, 17:39:00 CEST schrieb Stefan Brüns:
On Sonntag, 17. Juni 2018 17:08:40 CEST Axel Braun wrote:
Hi,
we had some days ago a discussion on how to prevent postgres10 installation,
as postgres96 is required: [...]
I think you are trying to solve the problem on the wrong level. Obviously, GH needs postgres in version 9.6, but how this requirement is met is out of scope for RPM. You can run PG as a local instance on a random, local port. You can run PG on a remote server or in a container on the same host.
Using update-alternatives is IMHO not an option, as it would change the system default, but still does not guarantee which database version will be used, e.g. if not running on the local host.
Both of your points above are true, but I would consider this as 'expert option' - they know what to do anyway. The target is to have a system up and running after the installation, with only minor interaction needed, and without the need to read a postgres-book beforehand.
This was all achieved out of a single package, but not anymore with postgres10 as default.
Probably, you should add a dependency on a metapackage, and provide different variants for this dependency: - one package configuring GH to use a remote PG instance - one package configuring GH to use a local PG instance, running on a randomized local port.
Do you maybe have an example?
I know of https://github.com/os-autoinst/openQA/blob/master/openQA.spec#L178 providing a local database for openQA for the most simple case of a single- user local setup. So a user can install this helper package. For any expert setup do not install the package and configure the database on your own
I had a look at the example, but I dont think it brings me forward. Ideally we have an option that sets the database used (similar as update- alternatives) per user - so all processes running for user xyz use postgres9. Anyone aware on such a configuration option? Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Axel Braun -
Oliver Kurz -
Stefan Brüns