https://bugzilla.redhat.com/show_bug.cgi?id=2145834 --- Comment #5 from dave@xxxxxxxxxxxx <dave@xxxxxxxxxxxx> --- (In reply to Benson Muite from comment #2) > Do all the Go libraries need to be bundled? This is a question I was expecting :-) and I think the answer is technically 'no', but practically 'yes'. Unfortunately I don't think it's practical for us to unbundle more than a very small number of the Go libraries here, which I'd argue doesn't really help much over leaving the dependencies fully bundled, and would create quite a lot more work. As an indirect justification for using fully bundled deps... singularity-ce is a container runtime, similar in scope to e.g. podman or apptainer. (Note that apptainer is an alternative fork/rename of the original singularity project... so it's currently quite similar to singularity-ce). podman uses bundled Go deps, which are declared in the spec (https://src.fedoraproject.org/rpms/podman/blob/rawhide/f/podman.spec) apptainer uses bundled Go deps, which haven't declared in the spec (https://src.fedoraproject.org/rpms/apptainer/blob/rawhide/f/apptainer.spec) More direct justification... * Generally, the go dependencies used by container runtimes tend to be an extremely complex web. We've had multiple occasions where we've had to use explicit replace directives in our go.mod in order to get a combination of versions of deps that will build / work correctly. E.g. https://github.com/sylabs/singularity/pull/443/files#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6 * We've also had times where a dep minor version update has caused a nasty regression, or we've had to go up to the HEAD of a dep's repo in order to fix something urgently. E.g. https://github.com/sylabs/singularity/pull/546 The trouble with catching these things, handling them, and preventing future issues, is that we rely on long-running end-to-end tests which require network access. Our upstream CI will run these tests always, so we can be reasonably confident about functionality with the bundled deps. It's not possible to run these extensive tests during an rpmbuild, and we don't really have the resources to run all of our tests on each golang library change across Fedora / EPEL versions. FWIW - we aggressively apply dependency updates to our main and release branches upstream, delaying only where unavoidable (https://github.com/sylabs/singularity/pulls?q=is%3Apr+build%28deps%29+is%3Aclosed+). This hopefully somewhat offsets the risk of unknown vulnerabilities / bugs hanging around in bundled deps. I've also tried to follow what I believe is best practice here (?), declaring the bundled deps (like podman does), rather than just using them without them being declared (like apptainer). I'm working through another packaging project for https://github.com/sylabs/scs-library-client, and there I am packaging missing deps, so that it can be fully unbundled. That is a much simpler piece of software, though, and much more straightforward to be confident about with unbundled deps. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2145834 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
