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 _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
