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

[Eric van Gyzen]

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