From owner-svn-src-head@freebsd.org Mon May 15 22:25:43 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 B5ACCD6EF83 for ; Mon, 15 May 2017 22:25:43 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 512E9359 for ; Mon, 15 May 2017 22:25:42 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 6b474f28-39bd-11e7-b96e-2378c10e3beb 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 outbound1.eu.mailhop.org (Halon) with ESMTPSA id 6b474f28-39bd-11e7-b96e-2378c10e3beb; Mon, 15 May 2017 22:25:38 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v4FMPVxU002277; Mon, 15 May 2017 16:25:31 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1494887131.59865.172.camel@freebsd.org> Subject: Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk From: Ian Lepore To: Alexey Dokuchaev Cc: John Baldwin , src-committers , Warner Losh , "svn-src-all@freebsd.org" , Ngie Cooper , "svn-src-head@freebsd.org" , Ngie Cooper , "Rodney W. Grimes" Date: Mon, 15 May 2017 16:25:31 -0600 In-Reply-To: <20170515210922.GA26702@FreeBSD.org> References: <201705131537.v4DFbgWV045290@pdx.rh.CN85.dnsmgr.net> <2229085.lB46rKsq7o@ralph.baldwin.cx> <1494870201.59865.103.camel@freebsd.org> <4703731.Pl02uSWy7k@ralph.baldwin.cx> <1494879113.59865.129.camel@freebsd.org> <20170515202853.GA88899@FreeBSD.org> <1494881370.59865.140.camel@freebsd.org> <20170515210922.GA26702@FreeBSD.org> 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: Mon, 15 May 2017 22:25:43 -0000 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