svn commit: r318441 - in head/etc: . cron.d

[Baptiste Daroussin]

On Thu, May 18, 2017 at 03:34:38PM -0600, 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?
> 

For now I don't know :) I'm thinking about it

Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20170518/4a1758af/attachment.sig>