https://bugzilla.redhat.com/show_bug.cgi?id=2145834 --- Comment #11 from Jonathan Wright <jonathan@xxxxxxxxxxxxx> --- (In reply to dave@xxxxxxxxxxxx from comment #10) > > Few more nitpicks: > > > > > W: non-conffile-in-etc /etc/bash_completion.d/singularity > > > > Bash completions are generally going in > > "%{_datadir}/bash-completion/completions/" these days. > > This is going to need upstream code changes or patches, if required, as our > makefile is using sysconfdir without the ability to override. Is this a > blocker, or something that we could tackle getting sorted out in the next > upstream release? Not a blocker, but would be great to see it changed in the future. > > > W: non-standard-dir-in-var singularity > > > > Applications must generally not add directories to the top level of /var. > > Such directories should only be added if they have some system-wide > > implication, and in consultation with the FHS mailing list. [1] > > > > Perhaps /var/lib/singularity would be a better fit? > > I believe the reason for using %{_localstatedir} (/var) is that when > Singularity was written, this location was chosen on the basis that it is... > > "The directory for installing data files which the programs modify while > they run, and that pertain to one specific machine." > (https://www.gnu.org/prep/standards/html_node/Directory-Variables.html) > > ... and the original author was purposely using %{_localstatedir} (/var) > rather than %{_sharedstatedir} (/var/lib) because we place a directory in > there that is used as a location (within a mount namespace) under which the > container filesystem is assembled before starting the container. To avoid > any issues with overlay mounts, namespaces etc. that can arise on network > filesystems, we require that this directory is on a local fs, which matches > the GNU definition of localstatedir above. > > I note, though, in the FHS document you linked, that the entry for /var/lib > refers to "state information is data that programs modify while they run, > and that pertains to one specific host"... so I suppose we could use > %{_sharedstatedir} here... it's just a bit odd the macro is 'shared' when we > need explicitly 'local' state. > > Modified the .spec file for this, and I'll have a think about how we can > tidy this up upstream... if we can. It does seem we should be following then > FHS definition, and not a GNU page... it's just a bit confusing with the > macro naming. I think this will be OK for now but should be changed in the future. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. 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
