From owner-svn-src-head@freebsd.org Thu May 18 21:27:53 2017 Return-Path: Delivered-To: svn-src-head@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 D438AD6F4D7 for ; Thu, 18 May 2017 21:27:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6DB3B94 for ; Thu, 18 May 2017 21:27:53 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: b228e9ad-3c10-11e7-8c46-c35e37f62db1 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id b228e9ad-3c10-11e7-8c46-c35e37f62db1; Thu, 18 May 2017 21:26:47 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v4ILRnjN002133; Thu, 18 May 2017 15:27:49 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1495142869.89384.18.camel@freebsd.org> Subject: Re: svn commit: r318441 - in head/etc: . cron.d From: Ian Lepore To: Baptiste Daroussin , John Baldwin Cc: rgrimes@freebsd.org, Ngie Cooper , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Date: Thu, 18 May 2017 15:27:49 -0600 In-Reply-To: <20170518212429.rugl6vnv5d2b2hpb@ivaldir.net> 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> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 21:27:53 -0000 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? -- Ian