Date: Tue, 18 Feb 2020 21:19:58 -0600 From: Will Andrews <will@freebsd.org> To: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Return of config files to ^/etc Message-ID: <CADBaqmgT032s38VjZO%2B0dELSLwW16PY-NY2Ky%2Bn3T8Rbn6SHWQ@mail.gmail.com> In-Reply-To: <CACNAnaE5kUuJiDOHtJSE357iiFrA2JQbNuEyLh5yZgU98X_t2g@mail.gmail.com> References: <CACNAnaE5kUuJiDOHtJSE357iiFrA2JQbNuEyLh5yZgU98X_t2g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 14, 2020 at 4:42 PM Kyle Evans <kevans@freebsd.org> wrote: > I've organized a review[0] to return most config files back to etc/. > Many people were concerned about the mass exodus of etc/, and many > have expressed a desire (privately or otherwise) for these files to > return- some of these folks represent downstreams or consumer projects > that went through the painful move the first time and would happily go > through the pain again to restore the status quo. > > This does mean that we'd end up with a structure that's not compatible > with stable/12, but is compatible with every branch before it. > > If you have an opinion for or against. please speak up now. I'd like > to make sure we're moving in the correct direction as a developer > community. > Hi, The original motivation of the change was to make packaging individual components easier. This in turn enables more incremental binary updates of the base system, via pkgbase. Not to mention, being able to install and manage a system with a subset of the full "base". Such capabilities would necessitate including config files with the binaries they configure, rather than shipping them as one large blob. Another nice feature that was gained is the ability to install all files for a particular component to a directory without having to use mtree or change to another directory to finish the job. At least for me, that's something I use frequently, installing to a DESTDIR for testing purposes, using `make install` like I do with every other project I've ever worked on. It's just a lot easier. I'd argue that, especially for embedded downstream consumer projects, the combination of these features would enable much more compact distributions and updates, while potentially continuing to use out-of-the-box FreeBSD binary packages. The long-time colocation of all etc files under one directory in FreeBSD src was always rather idiosyncratic. I would be hard pressed to name a single other project with multiple components whose configuration files were not stored alongside the source for the program which the files configure, but rather all in one place. One might argue that this is a feature, especially well suited for those who wish to examine the config files as a group in the source tree. It also means anyone working on a particular component must update files in multiple locations, if they are adding configuration. But for anyone coming to the project looking to work on devd or zfsd, for example, the notion will seem foreign. What other purpose do people gain from having them all together? Surely we aren't trying to enable people to copy them en masse, separate from the binaries they configure? This isn't necessarily correct or safe usage. I did review the proposed change briefly. Although it seems to preserve the above-mentioned build improvements, it does so at the cost of significantly expanding the search path for all components of the base system. The FreeBSD base build system is already glacially slow & inefficient as is, is it really worth making that worse? -- wca
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADBaqmgT032s38VjZO%2B0dELSLwW16PY-NY2Ky%2Bn3T8Rbn6SHWQ>