On Tue, Jan 23, 2024 at 11:58 AM David Trudgian via epel-devel <epel-devel@lists.fedoraproject.org> wrote: > > Hi all, > > I currently package singularity-ce for Fedora and EPEL. > > Upstream, we bundle current versions of squashfuse and conmon with our source > and own binary packages… because many distros package versions that are too > old to work with SingularityCE, and users installing our upstream binary > packages just want them to work. > > In Fedora & EPEL packaging I disable the building of the bundled squashfuse > and conmon in the spec file, and we rely on the distro’s squashfuse and > conmon packages. > > This is fine with Fedora, and has been okay up until now for EPEL. However, I > want to move forward with packaging SingularityCE 4.x for EPEL and there we > need a newer squashfuse than is available in EPEL7. Given our user base, > leaving EPEL7 without the update wouldn’t be popular, even if it is > approaching EOL. > > I wanted to verify if whether it's acceptable to bundle a newer squashfuse in > the SingularityCE package as a binary under our libexec dir, given that an > older squashfuse is provided by an existing squashfuse package? If so, are we > required to declare the bundling in the spec file, as we are doing for > bundled go deps in the spec? > > What has given me pause is reviewing the bundling guidelines at > https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling - where > it seems, at least for libraries, that a `Provides: bundled(<libname>) = > <version>` is required… and it’s not really clear to me whether the > discussion there about libraries can be directly applied to *executables* > that might be bundled? > > I note that the apptainer spec / package is already bundling a newer > squashfuse binary into its libexec dir without a corresponding Provides: … so > perhaps it’s fine to go ahead? Apologies if I have missed prior discussion on > this. > > https://src.fedoraproject.org/rpms/apptainer/blob/rawhide/f/apptainer.spec > https://packages.fedoraproject.org/pkgs/apptainer/apptainer/epel-7.html#files > > And it looks like their next release might be bundling a newer fuse2fs than > is in the distro e2fstools package too, plus a newer fuse-overlayfs than is > in the distro package: > > https://src.fedoraproject.org/rpms/apptainer/blob/rawhide/f/apptainer.spec > https://packages.fedoraproject.org/pkgs/apptainer/apptainer/fedora-rawhide.html#files
If you are bundling any software, you need to `Provides: bundled(software)`. This is so we can easily locate affected packages when e.g. a security issue necessitates fixing it. Also, since it wasn't clear from your text above: It's (generally) alright under these circumstances to bundle the extra packages, but you need to meet certain requirements: * The code that you're bundling still has to be built in Fedora. That probably means compiling it as part of your SingularityCE build. You may not ship code that was compiled somewhere else (e.g. upstream). * If you are shipping executables exclusively for use with your package, make sure they are properly namespaced in /usr/libexec/singularityce (or similar). This is to ensure that no other package accidentally tries to use your bundled version. -- _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
