The FSH standard 3.0 was introduced in 2015. The changes in FSH 3.0 seem to me as a natural evolution, and clarification of existing practices after the 2.3 version.
I believe we should officially adopt the 3.0 version and update the Fedora Packaging Guidelines text accordingly. Drop the obsolete paragraphs and review the list of exceptions, where we consciously want to deviate from the standard. The only question in my opinion is on how strict we should be with the Guidelines text update. Whether we want to document the state we *want to* achieve, trusting the package maintainers on their own to fix their packages where necessary, or rather make the list of exception as close to the current state in Fedora as possible, (e.g. acknowledging sub-dirs in '/usr/bin' as still acceptable for now) and hope some volunteer will later work towards fixing our distro as a whole - minimizing the number of expectations - through e.g. Fedora Changes. Another approach might be a combination - to have one list of the exception we want to keep for good reasons, and to make another list of exceptions we currently acknowledge, but want to remove, explicitly limiting these exceptions to the existing packages where the issues currently exists, so we at least prohibit new packages to introducing more such issues, and existing package to regress further away from the standard. Michal -- Michal Schorm Software Engineer Databases Team Red Hat -- On Tue, Aug 5, 2025 at 12:49 PM Pavol Sloboda <pslob...@redhat.com> wrote: > > Hello, > > I have just been going over the Filesystem Layout section[0] of the packaging > guidelines and I have noticed we are linking the Filesystem Hierarchy > Standard[1] as a whole and not a general version of it. At the moment there > are two versions mentioned on the linked website. These being v2.3 and v3.0. > It seems that Fedora is referring to version 2.3 at least based on this > statement in the guidelines: > `The Filesystem Hierarchy Standard does not include any provision for > libexecdir, but Fedora packages MAY store appropriate files there.` > So my questions are: > Which standard do we really support and shouldn't it be specified in the > guidelines? > And based on the previous question, should we update the above mentioned > statement to reflect the new guidelines? > > This whole effort was prompted by a question whether or not we can create > directories inside of `/usr/bin` and my gut tells me we shouldn't (as does > the 3.0 version of the Standard) but the 2.3 version of the standard does not. > > After a short query or the spec file tarball[3], I have found a couple of > packages which have their own directories inside /usr/bin, which should be > contacted if we agree to use the 3.0 version of the Standard. (I will provide > the list of packages and a way to query them if needed) > > [0] > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_filesystem_layout > [1] https://refspecs.linuxfoundation.org/fhs.shtml > [3] http://src.fedoraproject.org/repo/rpm-specs-latest.tar.xz > > Best regards, > > Pavol. > -- > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to 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/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
