From owner-freebsd-arch@freebsd.org Wed Feb 19 03:33:17 2020 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AA87824DBB5 for ; Wed, 19 Feb 2020 03:33:17 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Mjws3yV9z4cMJ; Wed, 19 Feb 2020 03:33:17 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 719B21ECC5; Wed, 19 Feb 2020 03:33:17 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f182.google.com with SMTP id u124so21270140qkh.13; Tue, 18 Feb 2020 19:33:17 -0800 (PST) X-Gm-Message-State: APjAAAV3gWXjWQBO+Nw6pV6MQ/pv0KT6ycNSpUV7jPoAz/p2Riq+kfUi vGMKF64E4WMrsOphY0uEDMAxzgSGyJbkwlAjS1U= X-Google-Smtp-Source: APXvYqw7IwPrrn3Ti+QpHW/WKja7+zj8ipYRxxHcUgUA3jwPN6R0YyWPo7RkCjxFV0IsvmKWj4Bpt+Hc2bDvVY8a/kU= X-Received: by 2002:a37:717:: with SMTP id 23mr18453149qkh.34.1582083196911; Tue, 18 Feb 2020 19:33:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Tue, 18 Feb 2020 21:33:05 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Return of config files to ^/etc To: Will Andrews Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 03:33:17 -0000 On Tue, Feb 18, 2020 at 9:20 PM Will Andrews wrote: > > On Fri, Feb 14, 2020 at 4:42 PM Kyle Evans 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