Date: Wed, 19 Feb 2020 07:02:09 -0700 From: Warner Losh <imp@bsdimp.com> 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: <CANCZdfopmua8LJJV-Z-%2Bb9Gq0z_DYxXJsarwhFFQOBdEiBhKZw@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 8: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. > Right. The files don't need to move from the original /etc to do this, and never did need to move. so this is not an argument against moving them back. > 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. > Again, done with proper makefile reach over, this can still be the case. > 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. > Since neither of these features strictly depends on where these files live in the tree, this advantage doesn't go away. > 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. > And people are used to it. They don't know where everything has moved and waste a lot of time finding stuff moved to a new, arbitrary location. > 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. > I'm not sure how big an advantage this actually is. > But for anyone coming to the project looking to work on devd or zfsd, for > nexample, the notion will seem foreign. > Those might reasonable exceptions. > 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 know where to go edit them. I have 30 years of knowing that the last few years haven't undone. > I did review the proposed change briefly. Although it seems to preserve > the > anbove-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? > I would humbly disagree: the change gets the best of both worlds. The vast majority of the files didn't need to move in the first place. Warner > -- > wca > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfopmua8LJJV-Z-%2Bb9Gq0z_DYxXJsarwhFFQOBdEiBhKZw>