Re: on rpms

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, 24 May 2022 at 18:55, Aurelien Bompard <abompard@xxxxxxxxxxxxxxxxx> 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.
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.


Yes I want to be clear. I wasn't saying pinning as much as a record of which packages were used. Most of the time, even 70% accuracy is better than 0%... [and here is the opening for various stories about when it is worse :)]. 



--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
_______________________________________________
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

[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux