From owner-freebsd-arch@freebsd.org Wed Feb 19 03:20:11 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 9620D24D80D for ; Wed, 19 Feb 2020 03:20:11 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Mjdk5hHLz4Fyl for ; Wed, 19 Feb 2020 03:20:10 +0000 (UTC) (envelope-from will@firepipe.net) Received: by mail-qt1-f176.google.com with SMTP id g21so167948qtq.10 for ; Tue, 18 Feb 2020 19:20:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1oCNZT+MgxDbid//japdOC7wWMC0hbkp6dHuRUoYpdQ=; b=hMP/fUMJ0TeVf1YjMA4X8cUOGVd8+nYl8eb12bqyyvmblpBIPe1MjiTbK7iSyJy0kW KHhiHbJhGsc7K+DlOCkUocU6V4wgNppdb4s04TlPJMP4TleJLwChnW3NPm8Z77LzvG3q YWF9Oo2kfLzy2aWRSVe+rA/sfgL90JNtkb9uaGd0DrU1TPoLfOmwY5Xmn1NeaW01GXfC v6fho5DDMUMyd5vIW2h1vokc+770xrkEtl+j23HoQvcNiNHoz1PLtZezMCMZtbfi5H6V IjLzs5JsiwXcF4DaGMezlll1+mVgWLlxQaT4D7+/uHhxyIRS0PyNRyGfLbTGA0eqO+Jf wMDQ== X-Gm-Message-State: APjAAAWlwZG7Mh+OAHSo836OT1zJMbxQ6N08IVzbWRmnWc0N7GY0vrjM tWKz0FSMEmURlXqigq30BluFchVhSpAdHlxnqKn/VBvz9V8= X-Google-Smtp-Source: APXvYqzvTI1uqKQ3E1MPeDnf6UKTWXaRIwN+qmr0RAxyZ3RAfHwhtRO2dQiBJEvnA4lfYdjDchR99Rm4ycQgVDn1ypg= X-Received: by 2002:ac8:405a:: with SMTP id j26mr20056157qtl.88.1582082409343; Tue, 18 Feb 2020 19:20:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Will Andrews Date: Tue, 18 Feb 2020 21:19:58 -0600 Message-ID: Subject: Re: Return of config files to ^/etc To: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 48Mjdk5hHLz4Fyl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of will@firepipe.net has no SPF policy when checking 209.85.160.176) smtp.mailfrom=will@firepipe.net X-Spamd-Result: default: False [-2.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.66)[ip: (-3.59), ipnet: 209.85.128.0/17(-3.00), asn: 15169(-1.68), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[176.160.85.209.list.dnswl.org : 127.0.5.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[will@freebsd.org,will@firepipe.net]; RWL_MAILSPIKE_POSSIBLE(0.00)[176.160.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[will@freebsd.org,will@firepipe.net]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:20:11 -0000 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. 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 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 From owner-freebsd-arch@freebsd.org Wed Feb 19 13:49:22 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 AFA7123AAE6 for ; Wed, 19 Feb 2020 13:49:22 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48Mzbk3bdVz46rL; Wed, 19 Feb 2020 13:49:22 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 01JDnJnL068750; Wed, 19 Feb 2020 05:49:19 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 01JDnJR5068749; Wed, 19 Feb 2020 05:49:19 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202002191349.01JDnJR5068749@gndrsh.dnsmgr.net> Subject: Re: Return of config files to ^/etc In-Reply-To: To: Kyle Evans Date: Wed, 19 Feb 2020 05:49:19 -0800 (PST) CC: Will Andrews , "freebsd-arch@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 48Mzbk3bdVz46rL X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.995,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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 13:49:22 -0000 ... trimmed ... > 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. EBUSY, ietf interim meeting tomarrow, after that I have some cycles. I am not so much opposed to having installs of the files spread out so much, as long as both the old behavior and new behavior BOTH work: cd /usr/src/etc; DESTDIR=/foo/bar make distribution vs what ever it is you have to do today to get a full prestine copy of /etc from base. I support the idea that a module/package should be able to pkg the config files BUTT a "make install" in any of them MUST not smash my etc/ files unless I explicitly enable that some how. I believe that is handled with make conf? I also have a very large desire to see this MFC'ed back to stable/12 so that there are only 12.0 and 12.1 being the odd mans out so support for this intermidiate state can be ended rather quickly. > Thanks, > Kyle Evans -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Wed Feb 19 14:02:25 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 27F5023AFC0 for ; Wed, 19 Feb 2020 14:02:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Mztm0dKKz4TTP for ; Wed, 19 Feb 2020 14:02:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id n17so247098qtv.2 for ; Wed, 19 Feb 2020 06:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uz+h7VLEGGJw5eFXTTAhoBwDEYl1uBqyfNSD8sQqwkk=; b=GwbfWxOO/xHcMUNILD+YSLhiXdfBH6OqLdj5wx1P8f5wjprsrEstyJxTpLGaTyd2c6 bZaJhZ9Ofx+LjT7Z3QZnzrJjREfIpfM6IwhYPxntxWrgI/tU81+Tyj+cKLslCAzZKxny 92Pc6pGTUiqrHMVfnbyBkh2ynk8ZLWsZpVWb2u3HdOHvDta61CicI9znMvLKBjfiXYFT 45Z1dcqcNLoOFUSlYnIeyKlsHa8UAVlAV4Jqq+NDrmk/MVUfFrlmqmTkpRe6FLm6DKhS VHNvunzGA2rDMZoWOkD1t0NUmEwkI+e6XkwYwtJ4Jv7J+Sa79nBT6M/q3S6683FTQ7eg T9qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Uz+h7VLEGGJw5eFXTTAhoBwDEYl1uBqyfNSD8sQqwkk=; b=h1ZjiNjcJU1Jq4/MyTH5+u8kGDHk7I2oe4JW42w+AZIpdhTnvFFdH7Um2wGNCSPYeF f3RMnbvX67GPLmz447EcA8XI2Z6L7jrzoiSV87VsYZNiaCzs31Nks8b77hbWwhca7zi6 zUiBCJ5n8BD5bZ6TjDrtIXXPjNgEmlJm6K8a3LecMV+4RoJwLCnvsFHGaH06Jh9ktDD0 zRedVt9vV3e9DoVyHy5l9qDSsP4501nIhYnFVP12sQLkvb1vPwd2J2WsgXFMn9nLXvAf SLJQ2SRezai4eje6wPjUBKcrgga1f1ACp1qg2njq8TMwq9uxaSCI04Knt5J6oDdc+bN+ QJRQ== X-Gm-Message-State: APjAAAWQ97PBld15Qrih4tW2lLFfx8nhs1Wy4MBvG7t/ibCfwBpv6hCd 9lL8Mw/vLoASOd4kNs7TlPAW7sKfK9caK25zrgS8Fg== X-Google-Smtp-Source: APXvYqx2ljAGo1+Utntjt0crOpYd7mmaMyu3u9XSz9YB0N4gBfuib84sxFFkTeaZHa4a5f8MZkJqo4zCrIQBAiAA29Y= X-Received: by 2002:ac8:1308:: with SMTP id e8mr22231665qtj.242.1582120942777; Wed, 19 Feb 2020 06:02:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 19 Feb 2020 07:02:09 -0700 Message-ID: Subject: Re: Return of config files to ^/etc To: Will Andrews Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 48Mztm0dKKz4TTP X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=GwbfWxOO; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::834) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.59 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.59)[ip: (-9.31), ipnet: 2607:f8b0::/32(-1.89), asn: 15169(-1.68), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 14:02:25 -0000 On Tue, Feb 18, 2020 at 8: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. > 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" > From owner-freebsd-arch@freebsd.org Wed Feb 19 15:14:33 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 ECBC923D3E7 for ; Wed, 19 Feb 2020 15:14:33 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48N1V05k7Cz4NT8 for ; Wed, 19 Feb 2020 15:14:32 +0000 (UTC) (envelope-from will@firepipe.net) Received: by mail-qk1-f180.google.com with SMTP id b7so406839qkl.7 for ; Wed, 19 Feb 2020 07:14:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Dux8792v5MlupckKkBAdkycUUI6yVT2nKYMV77pumXc=; b=MypG4+GF0+Os3U4YGPSE6/Sdx3AuKZt/xeFuHwlalD63EpbRwHQiPOFjvscbUIc+WT d8/JHTy8O4VUAevHZiPzywqLM6SBrF2kILeKYAbp7eyaFDsRgGfNx+GwCBoVpNRP549Z Epnx9txyPzJRO360BHqTnDnEpNDl4ahVlGPAejf/chA3lFbns/ncyWo63IbLPbA2hmac umKKIiiflSzzJLe4P7h17XuNUE57BpkzaTW3KCZ5OS99RaJxHVqr9mX+bTPyxDTFrHWq 4rGM8pF4oPa0or06P4C6O36tLUe1Jf/K9O79hTWVfHVEDaE+U364n6rBL5pYhCOgt+F1 lIog== X-Gm-Message-State: APjAAAXO2IiUd7ciGM7uVK1SmVFm2PZNv0R8KdCpeYO5btkPvnPkZZGQ FebBBZesuzKQyrPZF8qR18n7eSaT1nUXjTv5Z2hlk3sKrZI= X-Google-Smtp-Source: APXvYqzF3/TLubjvzMvnprgfDe4GdUmxuTvDtCOeiBqFUiYW1oWrQVs0Q1AdFZhhvXnTc1thRkIycKGHAbZJb3GwIX0= X-Received: by 2002:a05:620a:159b:: with SMTP id d27mr23185887qkk.426.1582125270865; Wed, 19 Feb 2020 07:14:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Will Andrews Date: Wed, 19 Feb 2020 09:14:20 -0600 Message-ID: Subject: Re: Return of config files to ^/etc To: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 48N1V05k7Cz4NT8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of will@firepipe.net has no SPF policy when checking 209.85.222.180) smtp.mailfrom=will@firepipe.net X-Spamd-Result: default: False [-2.41 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.61)[ip: (-3.33), ipnet: 209.85.128.0/17(-3.00), asn: 15169(-1.68), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[180.222.85.209.list.dnswl.org : 127.0.5.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[will@freebsd.org,will@firepipe.net]; RWL_MAILSPIKE_POSSIBLE(0.00)[180.222.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[will@freebsd.org,will@firepipe.net]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 15:14:34 -0000 On Wed, Feb 19, 2020 at 8:02 AM Warner Losh wrote: > > 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. > This was just the background. Since neither of these features strictly depends on where these files live > in the tree, this advantage doesn't go away. > But not new people, who in most cases are used to the standard that is followed by everything else (including everything installed by ports): config files with the code that reads it. That's why ^/etc is idiosyncratic. 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. > This seems to be the primary argument made for ^/etc: "that's the way it's always been done, so it must be right." I can think of a lot of things that are done a certain way primarily because of that argument. I'm sure I'm not alone. The new locations are actually less "arbitrary" (to use your word) than ^/etc, since the config files are co-located with the code that reads them. This is nice for source management: there's no need to look in or manage other directories for related files like the default configuration. It is a *source* tree, after all. Here's a question: why are config files special? Why don't we store all man pages in ^/share/man/manX, instead of colocating them with their source files? -- wca From owner-freebsd-arch@freebsd.org Wed Feb 19 15:34:02 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 1FBA823DAF4 for ; Wed, 19 Feb 2020 15:34:02 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48N1wS6tvtz40Jp; Wed, 19 Feb 2020 15:34:00 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 01JFXvfl069327; Wed, 19 Feb 2020 07:33:57 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 01JFXv2H069326; Wed, 19 Feb 2020 07:33:57 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202002191533.01JFXv2H069326@gndrsh.dnsmgr.net> Subject: Re: Return of config files to ^/etc In-Reply-To: To: Will Andrews Date: Wed, 19 Feb 2020 07:33:57 -0800 (PST) CC: "freebsd-arch@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 48N1wS6tvtz40Jp X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [0.93 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.32)[-0.324,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.32)[0.322,0]; IP_SCORE(0.03)[ip: (0.13), ipnet: 69.59.192.0/19(0.07), asn: 13868(0.03), country: US(-0.05)]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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 15:34:02 -0000 > On Wed, Feb 19, 2020 at 8:02 AM Warner Losh wrote: > > > > > 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. > > > > This was just the background. > > Since neither of these features strictly depends on where these files live > > in the tree, this advantage doesn't go away. > > > > But not new people, who in most cases are used to the standard that is > followed by everything else (including everything installed by ports): > config files with the code that reads it. That's why ^/etc is > idiosyncratic. > > 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. > > > > This seems to be the primary argument made for ^/etc: "that's the way it's > always been done, so it must be right." I can think of a lot of things > that are done a certain way primarily because of that argument. I'm sure > I'm not alone. Background. The layout of the BSD source tree reflects the layout of the installed system. It was by design decision long ago that src/etc should contain what goes in /etc, just as src/bin contain what goes in /bin. > > The new locations are actually less "arbitrary" (to use your word) than > ^/etc, since the config files are co-located with the code that reads > them. This is nice for source management: there's no need to look in or > manage other directories for related files like the default configuration. > It is a *source* tree, after all. And that src tree matches the binary tree, what your advocating, though sinceable, also has the negative side of removing that match. > > Here's a question: why are config files special? Why don't we store all > man pages in ^/share/man/manX, instead of colocating them with their source > files? Because man pages do not control the system configuration and can be installed at any time without any risk. Config files are special and must be treated special or "make installworld" is likely to clobber your system. > -- > 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" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arch@freebsd.org Wed Feb 19 15:54:08 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 F394C23E3E8 for ; Wed, 19 Feb 2020 15:54:08 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48N2Mg16gTz4RpL for ; Wed, 19 Feb 2020 15:54:06 +0000 (UTC) (envelope-from will@firepipe.net) Received: by mail-qk1-f174.google.com with SMTP id a141so539596qkg.6 for ; Wed, 19 Feb 2020 07:54:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=TlCAqRUiob4nH2pdMqKkwyv1T+QLn+L8c/oR6IMpO4A=; b=M/YYBFzR5rlte49y4EZu2IJGuu/vSCWMPYlUWLbzlQoFn5Wv7Es2iAc/ftZulafpYr 53OuokqPjPOvmoOmdbGSA/MKFlKjEglxfBGPgEKRR28B/XdB4sVVl9rb31SzHHasGed1 E/XGwU2LgxPPMKeJn2WaUuj/J8bZC33rLXNb8iRiiaL4AWKdl1nHUkgogvmDviRrz32P ne7UQpD5EoFWihBsgqrPUcUkhf0Hoy1csPUVOkQtBOdTM00zzf2rxjxMewKBnE/mz/jf OKIShteOCSY9nabjLw5wqYO7KDeGcdYZwW1gX8XGKAGGdwlsn94YQ7/qbEfHDRDEacZb wwqw== X-Gm-Message-State: APjAAAVPQvE6nQQIH8tQoemCv8tqWlXuo355Tlf8oQK9+RUgdAMnYtZv BOnVll/kHvlKnSObBsGEqfLrJmi7sdcqw3Hs0tFeUjrlxM4= X-Google-Smtp-Source: APXvYqxhLQ2BCfUTEUZ2cfKTlFbl2wQR1Flofk/bvwHu3vA/VBGjX1baATPre0N8R3S8ggu+sLf98jMWEZThsXs8TOg= X-Received: by 2002:a05:620a:989:: with SMTP id x9mr24663488qkx.371.1582127645489; Wed, 19 Feb 2020 07:54:05 -0800 (PST) MIME-Version: 1.0 References: <202002191533.01JFXv2H069326@gndrsh.dnsmgr.net> In-Reply-To: <202002191533.01JFXv2H069326@gndrsh.dnsmgr.net> From: Will Andrews Date: Wed, 19 Feb 2020 09:53:54 -0600 Message-ID: Subject: Re: Return of config files to ^/etc To: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 48N2Mg16gTz4RpL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of will@firepipe.net has no SPF policy when checking 209.85.222.174) smtp.mailfrom=will@firepipe.net X-Spamd-Result: default: False [-2.64 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-1.84)[ip: (-4.47), ipnet: 209.85.128.0/17(-3.00), asn: 15169(-1.68), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[174.222.85.209.list.dnswl.org : 127.0.5.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[will@freebsd.org,will@firepipe.net]; RWL_MAILSPIKE_POSSIBLE(0.00)[174.222.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[will@freebsd.org,will@firepipe.net]; RCVD_TLS_ALL(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 15:54:09 -0000 On Wed, Feb 19, 2020 at 9:34 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > Background. The layout of the BSD source tree reflects the layout of > the installed system. It was by design decision long ago that src/etc > should contain what goes in /etc, just as src/bin contain what goes > in /bin. > [...] > > And that src tree matches the binary tree, what your advocating, though > sinceable, also has the negative side of removing that match. > [...] > Because man pages do not control the system configuration and can be > installed at any time without any risk. Config files are special and > must be treated special or "make installworld" is likely to clobber > your system. > I'm aware the original intent was to reflect the layout of the installed system, but this hasn't been achieved, given the man page example. Also, config files don't have to be installed just because they're in the source directory instead of in ^/etc. -- wca From owner-freebsd-arch@freebsd.org Thu Feb 20 02:00:28 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 B388324DE13 for ; Thu, 20 Feb 2020 02:00:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48NHqG6YqQz4g7R for ; Thu, 20 Feb 2020 02:00:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-qt1-x844.google.com with SMTP id d9so1781377qte.12 for ; Wed, 19 Feb 2020 18:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7/cQaATVCGZ8PFSyFCROFFMdYLFWlvkiKXz6AVBJu8I=; b=UKjeBUVav3BgUEE5McgMI3LO7FQ3E75pFS7gOqJmV097ZHx4kmc1S+2d/RrEW3875m 7eyGHlYVffsUNqgQyAVphRowsZr4Jx2zZ8JQ/Hg4J2SCN/gspp43qOBqO3fGR2fyJl2F hC0zzRETdhiDcexY6dQdRRU6vq6GYB/DuMCDkAmeX9K9CzD/D+ttnBOzzfGt4VggwkPS 5B7X8ocuQdvvy+aBgmh8a8teGCjK/1+2OkUQFwiNKIqPVpjiqmB9dRaL85qr7/j7RX92 zPGhCTgiJNUiMOV7r9Svovz3PjNotACEn0EESWwn2V80CkB8bHSfVotXnnz+ylyk4kb9 dqDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7/cQaATVCGZ8PFSyFCROFFMdYLFWlvkiKXz6AVBJu8I=; b=uHaDz77B4VGkL+9oOsKpXd/CE4bcY0YL/OoVHGFMWE7MVKvDuJpd9yMRVlXiOYZVPj lrgqhJHN9Uv2EpZzIJiKPZFKSUTz99KCJ6uuGBNMKo9zf6Yr/TzrN9kSZPyJTaUDQ1xj Hb5rQCX5I9vyNAkJThzJGz0094lSTHdiY5GFBd91o0cVWg8rPxSwMJ+niuFAF75swnx9 xjGLV5bdGFXmXTwPNb0+y/XjGhaaZJM85Hq/TZbB35mAdC3p2ADGgR72XuSc8FijY1nS prFrvJtSeP5hLZVTbdtssifl7RCN/zSh8ztHzCeiJOvumNrBPOqRd1Gki5+S2wT/n//Z 5E2A== X-Gm-Message-State: APjAAAVgNdOqXpgVoMF1LWt3dHwTpad+oIxo1Jx/UED2k5tlB/cY164d wfQ9A17+5BJjdsNUvhZ1wkrCMYvivL8WRRrfdM8= X-Google-Smtp-Source: APXvYqwyF7/HeRlCjNI7YxE1w5k1ahVYK8aJVpTN0t7JWh6aB1dS+pD01/2mbwHDyAzfuYbMF/WWZT6gaYB0g/Pv2HA= X-Received: by 2002:ac8:6054:: with SMTP id k20mr23837880qtm.92.1582164025561; Wed, 19 Feb 2020 18:00:25 -0800 (PST) MIME-Version: 1.0 References: <6701.1581190231@critter.freebsd.dk> <97A66670F59C9C626B5090E3@triton.njm.me.uk> <8967.1581243035@critter.freebsd.dk> <55C50689-6DA8-4D44-92BB-72C38B54AC96@cschubert.com> <202002091350.019DoZrf084564@slippy.cwsent.com> <202002091605.019G5Csj051412@slippy.cwsent.com> <584.1581370678@kaos.jnpr.net> In-Reply-To: From: Adrian Chadd Date: Wed, 19 Feb 2020 18:00:13 -0800 Message-ID: Subject: Re: updating cron and atrun To: Xin LI Cc: "Simon J. Gerraty" , Josh Aas , Poul-Henning Kamp , "N.J. Mann" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 48NHqG6YqQz4g7R X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=UKjeBUVa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of adrianchadd@gmail.com designates 2607:f8b0:4864:20::844 as permitted sender) smtp.mailfrom=adrianchadd@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (2.05), ipnet: 2607:f8b0::/32(-1.89), asn: 15169(-1.67), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-Mailman-Approved-At: Thu, 20 Feb 2020 06:12:40 +0000 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: Thu, 20 Feb 2020 02:00:28 -0000 On Mon, 10 Feb 2020 at 20:59, Xin LI wrote: > > Also note that it's not something that is high effort at all, because > others have already implemented it, and did so in less than 700 lines of > code, with license block included. I'd say bringing OpenBSD cron is a low > hanging fruit if someone wants to do something in the project, and IMHO > there is no reason to remove the functionality because of that. > > I have worked on bringing OpenBSD cron to FreeBSD a while ago (I think it > was ~2012) but never committed it because subversion made my life hard > (well, partially -- I should have created a branch on user/ but I didn't) > to keep my local patches on the move to the point that eventually I have > gave up maintaining it. Hm, just a note - vixie mentioned about putting his base cron online and ifdef'ing in freebsd bits. The twitter thread talks about openbsd. https://twitter.com/paulvixie/status/1214286886094589952 Maybe reach out to him? :) -a From owner-freebsd-arch@freebsd.org Fri Feb 21 18:24:19 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 3CE0023E2F8 for ; Fri, 21 Feb 2020 18:24:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 48PKc30Z27z3LnF; Fri, 21 Feb 2020 18:24:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-7.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 8AE761B1F5; Fri, 21 Feb 2020 18:24:18 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Return of config files to ^/etc To: Will Andrews , "freebsd-arch@freebsd.org" References: From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Fri, 21 Feb 2020 10:24:15 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Fri, 21 Feb 2020 18:24:19 -0000 On 2/19/20 7:14 AM, Will Andrews wrote: > The new locations are actually less "arbitrary" (to use your word) than > ^/etc, since the config files are co-located with the code that reads > them. This is nice for source management: there's no need to look in or > manage other directories for related files like the default configuration. > It is a *source* tree, after all. > > Here's a question: why are config files special? Why don't we store all > man pages in ^/share/man/manX, instead of colocating them with their source > files? Yes, why are (some) config files special? Why is rc.d still intact but just moved to a more obscure location (libexec/rc). Why is pam.d still intact and not split up? Why is stdio.h in include/? Both the old and new arrangements are arbitrary, so why gratuitously break existing muscle memory and setups (we've already moved the libc ones back to etc/ in head due to breaking other tools)? -- John Baldwin