On Wed, May 25, 2022 at 12:54:57AM +0200, Aurelien Bompard wrote:
> As a package maintainer... I LOATHE pinning. ;(
>
Let me rephrase that and please tell me if I'm correctly representing your
thoughts.
You loathe somebody else deciding which dependencies you must use.
That's fair, it's a distro packager's hell.
Yeah, in a distro you need to integrate the thing with all the other
things and come up with versions that they can all use/share. If
something is pinned to a specific version it often indeed causes doom
because all the other things have moved on or havent yet and you have to
reconcile that with them.
However in this case I think it's pretty different: we control
both the
pinning and the packaging (well, image building).
well, sure, but it makes it hard for someone else to package it if they
want to. :)
In a way, using RPMs does not guarantee reproducibility either: if my
app
depends on libA-X.Y and it works when I build it, but then libA's
maintainer decides to update to X.Z and it breaks my app when I rebuild the
image, then having an RPM of my app does not help. To ensure
reproducibility we need the versions of the RPMs used at build time, and
that's pretty similar to the versions that pip would have pulled at image
build time.
Indeed.
So, in our case, I suppose storing the list of all versions used
would
suffice. Or even better: let's store the images themselves and version
them. Can the internal OpenShift registry reliably do that? Do we need to
switch to something external (quay.io?) to reduce the chance of everything
failing at the same time? Then it does not matter whether we track a branch
or a commit, we can rollback to the code that was used before by using the
previous image. Provided there was no DB schema upgrade, but that's another
can of worms.
Yeah, saving images sounds good to me for the openshift case.
As long as we can rollout an old version we know was working, I think
thats just fine. I would prefer not to depend on any external providers
for that if we can at all.
So, perhaps we need a little tinkering here... take some app...and
confirm we can successfully rollout an older version. If we can do that,
I think we are fine, pinning or not pinning. At least for the purposes
of our deployment. I think that does make it harder for people to
package our things, but I suppose thats really an upstream decision how
tightly to pin.
kevin