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.
However in this case I think it's pretty different: we control both the pinning and the packaging (well, image building).
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.
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.
Aurélien
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
