dependency: update influxdb-client-go to v2.14.0

[come-maiz]

The diff in influxdb-client-go:
influxdata/influxdb-client-go@v2.4.0...v2.14.0

[come-maiz]

We are packaging geth for debian: https://collective.flashbots.net/t/geth-go-ethereum/4873#p-10032-debian-packaging-1

For this we are reviewing the whole chain of dependencies, reporting issues and proposing updates where things haven't been touched in a while. Frequent dependency updates makes it easier to audit the changes, to test for any possible regressions, and to have a relation with the other projects.

In this case, the most recent influxdb-client requires https://github.com/oapi-codegen/runtime/ which was renamed some time ago. By updating this dependency, in addition to the usual benefits, we will be able to add the runtime library without any redirections. Everything is easier for the maintenance in Debian if the dependencies are fresh.

[fjl]

Hi @come-maiz, I do not fully understand your concerns regarding Debian packaging. Please elaborate on the build process used. If possible, please also link to packaging scripts that you are working on.

In order to produce a working geth package, the go-ethereum source is meant to be built with the exact versions of the dependencies listed in go.mod. Please do not build geth with other versions of the these modules.

For Ubuntu, we offer source debian source packages via launchpad.net. These packages contain a snapshot of the source code of all dependency packages. If you want, we can produce a source snapshot like that for use by Debian for each release.

[come-maiz]

Thanks for your words @fjl.

This project I'm working on is to get Ethereum binaries and libraries into the debian archive.

This is the intent to package bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890541
This is the wiki were I track our progress: https://collective.flashbots.net/t/geth-go-ethereum/4873#p-10032-debian-packaging-1

The launchpad packages are appreciated. They are not enough to be maintained in the debian archive. For this we have to get all the dependencies packaged and reviewed first, and not bundle, vendor or duplicate anything. This project started because for Flashbots research we need reproducible builds and risc-v support, and going through debian gives us also transparency, more maintainers and reviewers, more testers, and many other things that I can't predict and I'm sure will come :)

The thing with this PR is that if I package influxdb-client-go v2.4.0, I will have to package github.com/deepmap/oapi-codegen. In may 2024, this project was renamed github.com/oapi-codegen/oapi-codegen. So I would have to package the old version, a migration, and the new version. Which of course it's ok if I have to do it, not too complicated.

I want to do it differently, and also build a relation with the downstream libraries, upstream binaries and meta maintainers. By keeping the dependencies fresh, it will be easier to prevent a supply chain attack because the diff will be readable. We can also start noticing which dependencies are trustworthy, which need support, and which are suspicious. We can also start reducing the number of our dependencies to what's actually necessary, split big projects, collaborate differently. We are doing this bottom-up review and having these conversations as we find old and risky dependencies. Saying hi, meeting the humans, seeing who wants to walk together.

Those were a lot of words, and of course I have more :D Let me know if you have any questions.