From owner-svn-src-all@freebsd.org Thu May 18 21:36:59 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AD47D6F9F9; Thu, 18 May 2017 21:36:59 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id 07050169B; Thu, 18 May 2017 21:36:59 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 34D575646B; Thu, 18 May 2017 16:36:58 -0500 (CDT) Subject: Re: svn commit: r318441 - in head/etc: . cron.d To: Ian Lepore , Baptiste Daroussin Cc: John Baldwin , rgrimes@freebsd.org, Ngie Cooper , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org References: <201705180625.v4I6Pd9j062495@repo.freebsd.org> <201705180956.v4I9uVpQ065465@pdx.rh.CN85.dnsmgr.net> <20170518130932.eo5clhki4za2vigz@ivaldir.net> <2201156.H7EQSgYph9@ralph.baldwin.cx> <20170518212429.rugl6vnv5d2b2hpb@ivaldir.net> <20170518212911.mstgmzbydsv7oind@ivaldir.net> <1495143278.89384.24.camel@freebsd.org> From: Eric van Gyzen Message-ID: <10f3d402-f392-d4ed-cc47-76296f0ef4e7@vangyzen.net> Date: Thu, 18 May 2017 16:36:57 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <1495143278.89384.24.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 21:36:59 -0000 On 05/18/2017 16:34, Ian Lepore wrote: > On Thu, 2017-05-18 at 23:29 +0200, Baptiste Daroussin wrote: >> On Thu, May 18, 2017 at 03:27:49PM -0600, Ian Lepore wrote: >>> >>> On Thu, 2017-05-18 at 23:24 +0200, Baptiste Daroussin wrote: >>>> >>>> On Thu, May 18, 2017 at 09:48:25AM -0700, John Baldwin wrote: >>>>> >>>>> >>>>> On Thursday, May 18, 2017 03:09:32 PM Baptiste Daroussin wrote: >>>>>> >>>>>> >>>>>> On Thu, May 18, 2017 at 02:56:31AM -0700, Rodney W. Grimes >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> [...] >>>>> The support for broken out files has long been there, but the >>>>> base >>>>> system has >>>>> not used them previously for default config shipped during a >>>>> release. That >>>>> is in fact a new trend. >>>>> >>>>> However, the current approach seems to be the absolute worst >>>>> way to >>>>> do this. >>>>> If someone wants to use the existing base system image and >>>>> modify >>>>> it with >>>>> config management, they now have to use a mix of styles (for >>>>> some >>>>> services >>>>> edit a global config file for certain settings, but use a >>>>> dedicated >>>>> file for >>>>> other settings for the same service, or for the same settings >>>>> but a >>>>> different >>>>> service). It's also the worst case for humans trying to work >>>>> with >>>>> our system >>>>> as the division between which services are broken out vs global >>>>> is >>>>> inconsistent and arbitrary. >>>>> >>>>> Once you split up the files you make a merge conflict for >>>>> anyone >>>>> trying to do >>>>> an upgrade. If we do this piecemail then we create N merge >>>>> conflicts for users >>>>> to deal with as opposed to if you split it up all at once. >>>>> >>>>> Also, there wasn't a clear consensus (a mail to arch@ with >>>>> "hey, we >>>>> should >>>>> switch to splitting up config files for reasons A and B and >>>>> let's >>>>> do this for >>>>> 12.0 but not merge to stable so there is a clear flag day / >>>>> sign >>>>> post for users >>>>> to manage upgrades". Instead there have been a couple of >>>>> commits >>>>> and any >>>>> not-in-100%-agreement opinions are ignored. >>>>> >>>> That's true, another thing is the way it is done, there is no >>>> simple >>>> way to >>>> disable the at cron from an admin point of view rather than rm >>>> /etc/cron.d/at >>>> for an end user which an upgrade will bring back. >>>> >>>> Bapt >>> Would you not just comment out or delete the line, exactly as you >>> would >>> do in the main /etc/crontab? >> Right but with a .d directory I would expect to just remove/add >> files/symlinks >> rather than editing it, which defeat the point of the .d >> >> Bapt > > Hrm, I don't see any conflict between "this fine-grained file holds > config for just one component" and "edit the file if you want to change > the config". That is, making the file fine-grained is to make editing > it EASIER (for a human or a program), not to eliminate editing it. > > I do see how thinking that deleting the file (or renaming it to file.no > or something) would seem like the right thing to do. How can we fix > that? How would an upgrade bring back /etc/cron.d/at if the end-user deleted it? Eric