svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ian Lepore]

On Mon, 2017-05-15 at 21:09 +0000, Alexey Dokuchaev wrote:
> On Mon, May 15, 2017 at 02:49:30PM -0600, Ian Lepore wrote:
> > 
> > ...
> > You acknowledge that the situation is different for ports, so does that
> > mean your objections go away when base becomes packaged and faces the
> > same installation and update issues that packaged ports do?  Because I
> > was under the impression that's coming pretty soon.
> The reason it is different for ports is because we cannot know up-front what
> software might user have installed and ergo what logs should be rotated by
> newsyslog(8).  For the base, we know these pieces (albeit packaging the base
> could probably benefit from the same generic approach, if we ever start to
> support 3rd-party "base" packages).
> 
> ./danfe
> 

The same is true of packaged base -- the user may have installed a
subset of the base system.  No need to configure ftp log stuff if ftp
didn't get installed.  Likewise for ntp, mail, news, everything that
has its own syslog facility code.

And really, while syslog config started this thread, most of what I've
been saying is more widely related to my initial comment:  moving from
monolithic to per-subsystem/object/whatever config files has been the
freebsd trend for a while.  That's not just for syslog rotation, that's
for rc config and jail config and pam (maybe where the trend started?)
and devd and periodic jobs and so on.

Most of these things support both a single file and individual files,
so nobody is forced to change all at once, but it does seem natural
that the existing base code evolve towards the newer mechanism.  When
it makes sense to still have the original file and only split out parts
of it to individual files, it might also make sense to drop a comment
into the original file to let old-timers know they should go looking in
the newer directory for additional entries.

Or it might makes sense to say: no half measures for a given
configuration scheme, if some items are to be split out to separate
files, then everything should be split, so that before the next major
release there is only a monolithic file, or a directory full of fine-
grained config, but not a mix.  I'm not advocating for that
necessarily, just thinking out loud really.

-- Ian