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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
