> What I'm try to convey is that the way that we put together Linux systems > is evolving, slowly but continuously, and we need documents that describe > this evolution. A "standard" that tries to turn back time and slow down > this process is not useful.
I agree with this logic, yet what we have at the moment is far from it. It is an amalgamation of the old Standards and the evolving way to document the way the system is structured you are talking about. Not even an up to date one. Dropping the standard altogether would be the "best" way to keep an evolving system. But considering the time (or lack thereof) that is being dedicated to the documentation of this part of the system, I don't think it is feasible to just write our own rules and we have to have a base to start from. Therefore I don't think the current way we do it is terrible. Using a standard gives us a base to build up on with exceptions and additions (using one from 2004 is not the way ofc). But choosing the correct, and most up to date, standard is a key to this process. On Thu, Aug 7, 2025 at 11:24 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Wed, Aug 06, 2025 at 05:59:45AM -0700, Neal Gompa wrote: > > On Wed, Aug 6, 2025 at 5:55 AM Pavol Sloboda <pslob...@redhat.com> > wrote: > > > > > > > But it's already done? It's right there. > > > > > > Well as my email mentions it is done for FHS 2.3 (and not even that > really cause the version of the Standard is not mentioned anywhere). > > > And what I am trying to ask about is either switching to a newer and > more up to date Standard or having a concrete mention of > > > the standard we are using at the moment and addressing the new things > that have been changed lately (e.g.: the abovementioned > > > `/usr/bin` `/usr/sbin` merge). > > > > > > > There's already a ticket for FHS 4.0 to include bin-sbin merge: > > https://gitlab.freedesktop.org/FHS/fhs-spec/-/issues/4 > > > > Same for /usr Merge: > https://gitlab.freedesktop.org/FHS/fhs-spec/-/issues/3 > > "already". I think those two tickets illustrate the issue very well: > they are ~9 months old, nobody is working it implement them, > and they went dead after some initial discussion. And the "discussion" > that was there was pretty sad. The actual discussion already happened > on fedora-devel 15 years ago (for usr-merge) and last year (for > sbin-merge) and in the systemd upstream. It's not very interesting to > see the old arguments being rehashed. > > And considering that systemd has dropped support for split-usr > hierarchies, the discussion is really over. > > What I'm try to convey is that the way that we put together Linux systems > is evolving, slowly but continuously, and we need documents that describe > this evolution. A "standard" that tries to turn back time and slow down > this process is not useful. > > Zbyszek > > -- > _______________________________________________ > 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
