From owner-svn-src-head@freebsd.org Thu May 18 16:52:07 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 DDB04D72A93 for ; Thu, 18 May 2017 16:52:07 +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 C1E8F151B for ; Thu, 18 May 2017 16:52:07 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 04103c96-3bea-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 04103c96-3bea-11e7-8c46-c35e37f62db1; Thu, 18 May 2017 16:49:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v4IGouZ7001606; Thu, 18 May 2017 10:50:56 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1495126256.93532.14.camel@freebsd.org> Subject: Re: svn commit: r318441 - in head/etc: . cron.d From: Ian Lepore To: rgrimes@freebsd.org, Ngie Cooper Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Thu, 18 May 2017 10:50:56 -0600 In-Reply-To: <201705180956.v4I9uVpQ065465@pdx.rh.CN85.dnsmgr.net> References: <201705180956.v4I9uVpQ065465@pdx.rh.CN85.dnsmgr.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 16:52:08 -0000 On Thu, 2017-05-18 at 02:56 -0700, Rodney W. Grimes wrote: > > > > Author: ngie > > Date: Thu May 18 06:25:39 2017 > > New Revision: 318441 > > URL: https://svnweb.freebsd.org/changeset/base/318441 > > > > Log: > >   Handle the cron.d entry for MK_AT in cron conditionally > >    > >   Install /etc/cron.d/at if MK_AT != no, always using it, which > > tries > >   to run a non-existent program via cron(8) every 5 minutes with > > the > >   default /etc/crontab, prior to this commit. > >    > >   SHELL and PATH are duplicated between /etc/crontab and > > /etc/cron.d/at > >   because atrun(8) executes programs, which may rely on environment > >   currently set via /etc/crontab. > >    > >   Noted by: bdrewery (in an internal review) > >   MFC after: 2 months > >   Relnotes: yes (may need to add environmental modifications > > to > >         /etc/cron.d/at) > >   Sponsored by: Dell EMC Isilon > > > > Added: > >   head/etc/cron.d/ > >   head/etc/cron.d/Makefile   (contents, props changed) > >   head/etc/cron.d/at   (contents, props changed) > > Modified: > >   head/etc/Makefile > >   head/etc/crontab > > > > Modified: head/etc/Makefile > > =================================================================== > > =========== > > --- head/etc/Makefile Thu May 18 06:15:42 2017 (r3184 > > 40) > > +++ head/etc/Makefile Thu May 18 06:25:39 2017 (r3184 > > 41) > > @@ -8,6 +8,7 @@ FILESGROUPS= FILES > >  # No need as it is empty and just causes rebuilds since this file > > does so much. > >  UPDATE_DEPENDFILE= no > >  SUBDIR= \ > > + cron.d \ > >   newsyslog.conf.d \ > >   syslog.d > The thread on the newsyslog clearly shows that this is a > contriversial change. > > I strongly object to further splitting of /etc/FOO into > /etc/foo.d/FOO files > to suite Dell/EMC/Isilon's needs.  It is in conflict with the needs > and > desires of others. > Actually, the newsyslog thread showed that 4 people supported Ngie's changes, and 4 people objected to them.  Not exactly a raging controversy.  Given how many people read this list, a pretty tepid response really. The objections seemed to boil down to:  1. It's not how we've done it for years; I don't like newfangled stuff.  2. It's strange to have some stuff in the old monolithic file and some in new little files in a directory.  3. It will be hard to update existing systems. I don't see any point in discussing #1 further (not because peoples' opinions don't matter, but rather because there will never be universal agreement no matter how much it's discussed). I think #2 has some validity, but not as an argument for stopping or undoing the changes, but more as a valid design issue to be discussed.  Do we need an "all or nothing" rule when it comes to changing existing config files to be fine-grained?  Or some other rule?  Right now I infer the rule Ngie is using to be "if you can disable a component with build/install controls, then its config should be fined-grained", and that strikes me as a workable rule, but not the only one possible. #3 seems like a strongly valid concern.  People following -current have agreed to take on some pain to do so, but when 12.0-release hits the streets there needs to be a way to upgrade existing systems without a lot of pain.  What can we do to make it easier? -- Ian