Date: Tue, 18 Feb 2020 21:33:05 -0600 From: Kyle Evans <kevans@freebsd.org> To: Will Andrews <will@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Return of config files to ^/etc Message-ID: <CACNAnaFL-xDYHS3YqTXB_LO%2BbJAcYhSPE8cA9qwqTFVXxtDdkQ@mail.gmail.com> In-Reply-To: <CADBaqmgT032s38VjZO%2B0dELSLwW16PY-NY2Ky%2Bn3T8Rbn6SHWQ@mail.gmail.com> References: <CACNAnaE5kUuJiDOHtJSE357iiFrA2JQbNuEyLh5yZgU98X_t2g@mail.gmail.com> <CADBaqmgT032s38VjZO%2B0dELSLwW16PY-NY2Ky%2Bn3T8Rbn6SHWQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 18, 2020 at 9:20 PM Will Andrews <will@freebsd.org> wrote: > > 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. > brd@ raised this concern to me privately, and I had asked him to do so here on -arch@ as well, but he has not yet done so -- I suspect he's been busy. I don't personally find this particularly compelling (because I don't do this), but I'd like to hear opinions from the broader community as well. > 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. > Agreed. Also, all of my upgrades are via pkgbase at the moment, and have been for the past ~3.5ish years if the tags I leave on my git repo are to be believed; I have a good amount of personal stock in seeing the project succeed. > 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. > This I'm also not unsure of- it seems to be one of those one-time hurdles... you discover that they're located in ^/etc, then the layout would seem to be kind of intuitive from there as long as we're consistent. > 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? > Indeed- this is just one proposal. rgrimes had other concerns with leaving installation where it was previously moved to- he was going to raise this and other concerns here on -arch@, but I reckon he got a bit busy as well. I'm not opposed to moving the installation into ^/etc since we can still guarantee it'll get packaged correctly. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaFL-xDYHS3YqTXB_LO%2BbJAcYhSPE8cA9qwqTFVXxtDdkQ>