On Mon, 11 Dec 2023 at 12:34, Neal Gompa <ngomp...@gmail.com> wrote: > On Mon, Dec 11, 2023 at 11:36 AM David Cantrell <dcantr...@redhat.com> > wrote: > > > > On 12/8/23 10:25, Stephen Gallagher wrote: > > > On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek > > > <zbys...@in.waw.pl> 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@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 > -- 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@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
