On Mon, 11 Dec 2023 at 12:34, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Mon, Dec 11, 2023 at 11:36 AM David Cantrell <dcantrell@xxxxxxxxxx> wrote:
>
> On 12/8/23 10:25, Stephen Gallagher wrote:
> > On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek
> > <zbyszek@xxxxxxxxx> wrote:
> >>
> >> Hi,
> >>
> >> There is a long-term goal of moving packaged files out of /etc, so that
> >> only actual local configuration remains in /etc. This has some advantages:
> >>
> >> - Local configuration, i.e. the result of local administrative actions,
> >> is nicely split from static configuration that is part of package payload.
> >> 'find /etc' will show what is special to this local system, while
> >> 'find /usr' lists stuff that is part of packages and the same between
> >> systems.
> >> - We can support "factory reset" at the system level, i.e. do 'rm -rf /etc'
> >> to return everything to distro defaults. We're not there _yet_, but it
> >> works with a surprisingly large subset of packages.
> >> - We can support "factory reset" at a package level, by removing all the
> >> configuration and state of an individual package, without reinstalling it
> >> (possibly combined with some tmpfiles.d config to recreate things
> >> automatically.)
> >> - It becomes easier to build systems which are delivered as a stand-alone
> >> /usr-partition. This could be ostree-style systems, or image-based systems
> >> with the /usr-partition read-only and protected by dm-verity. We're not
> >> there _yet_, but many people are experimenting with this.
> >>
> >> When one looks in /etc, many of the files there are not "configuration".
> >> For example, /etc/services is a list of port:service mappings, and people
> >> maybe used to edit that twenty years ago, but now it's just a static file
> >> that just as well may be somewhere under /usr/lib/. The same is also
> >> true for /etc/bash_completion.d/ — people do not edit completion scripts.
> >> Most of those have been moved to /usr/share/bash-completion/completions/,
> >> but there's still a dozen or so in /etc.
> >>
> >
> > One thing that is becoming much more common is for us to ship such
> > static files in /usr/lib and include a default symlink in /etc for
> > those packages whose presence there is effectively API (for example
> > /etc/os-release is a symlink to /usr/lib/os-release, similarly
> > /etc/resolv.conf). I think this is a very good approach and one that
> > we should probably look at formalizing in the packaging guidelines.
>
> I'd rather see defaults under somewhere in /usr/share rather than /usr/lib.
>
I agree with this. I really would rather it be in /usr/share.
> > That being said, there are files like /etc/nsswitch.conf, /etc/pam.d/*
> > and /etc/fstab which are both API *and* sometimes see manual updates.
> > These are some of the cases that are going to make getting to an empty
> > /etc very hard to finish off. There's a lot of low-hanging fruit we
> > can take care of in the meantime, but getting the last 1% of packages
> > done is going to take a lot of inter-distro conversations.
>
> We could just have an /etc tree like we see now but in /usr/share/etc
> (or /usr/etc, but then I get IRIX nightmares) and your local overrides
> exist in /etc. Things like fstab will probably just have to always be
> host-dependent so they will always exist in /etc.
>
We're currently not allowed to use /usr/etc (not that I like that path
anyway) because it breaks RPM-OSTree. My understanding is that this
directory is reserved by RPM-OSTree for storing pristine copies of
/etc content for each OSTree commit.
My other problem with using /usr/etc is if we decide in N years that we want to get rid of /usr altogether (reverse usrmerge so /usr/sbin -> /sbin, /usr/bin -> /bin etc) and put everything at top-level.. we have to then figure out where we would put all this content anyway.
At some point I think we are also looking at large enough changes that we need to 'update FHS' and similar guidelines mainly so that third party standards and tools can know where things 'should' go.
> For this to be really clean and nice, everything that drops a file in
> /etc needs to handle the "read in the default; then read in the optional
> local overrides" model. I know a lot of stuff already does this, but
> some things don't. It would be a nice goal to aim for and maybe we can
> submit patches to upstream projects where the functionality is missing.
>
Indeed.
--
真実はいつも一つ！/ Always, there's only one truth!
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
