search

dpage / winpgbuild

A repo containing Github actions for building PostgreSQL and it's dependencies on Windows
1 stars 2 forks source link

Add pkgconf to deps #24

Closed anarazel closed 2 months ago

anarazel commented 2 months ago

For some reason choco install is very slow. And explicitly specifying the version is good for reproducibility anyway.

If desirable I can add a matrix to postgresql-dev showing what can be built with and without pkgconf.

dpage commented 2 months ago

I was also thinking of doing this, however, is there any particular reason to build it ourselves rather than just downloading the pre-built version as we're doing with other tools?

anarazel commented 2 months ago

I was also thinking of doing this, however, is there any particular reason to build it ourselves rather than just downloading the pre-built version as we're doing with other tools?

The choco version just downloads something from some random old sourceforge project that hasn't been updated in years. And the pkgconf project doesn't provide pre-built packages on github. There are some, but they're again on some random website. You said you were concerned about supply chain stuff, so it seems better to not download stuff from random websites...

anarazel commented 2 months ago

I added a comment explaining why it's built ourselves.

I'm not merging this myself as I don't seem to have the permissions to add PKGCONF_VERSION=2.2.0 to the repo variables.

davecramer commented 2 months ago

Ya, getting commit doesn't get you the ability to change the settings.

davecramer commented 2 months ago

I wonder if there is another way to specify the versions so that they are 1) visible, and 2) easily updatable ?

anarazel commented 2 months ago

Thanks for merging!

I wonder if there is another way to specify the versions so that they are 1) visible, and 2) easily updatable ?

Yea, I have wondered about that too. One can have dependencies between jobs and use the output from one in another. We could have one job that just prints out the set of dependencies as json that then all the others consume.

That does mean the list of dependency versions is in the repo, but I'm not sure that's actually bad?

davecramer commented 2 months ago

Thanks for merging!

I wonder if there is another way to specify the versions so that they are 1) visible, and 2) easily updatable ?

Yea, I have wondered about that too. One can have dependencies between jobs and use the output from one in another. We could have one job that just prints out the set of dependencies as json that then all the others consume.

That does mean the list of dependency versions is in the repo, but I'm not sure that's actually bad?

Well we discussed publishing it somewhere. We aren't hiding it, nor should we.

dpage commented 2 months ago

I was thinking that we'd just have every build write a "manifest" file as part of its output, that would identify the version and maybe any other useful info. Uploaded artefacts would then just include that file. Let's continue this discussion on the more appropriate #20 issue though.