From owner-svn-src-all@freebsd.org Wed Jun 6 11:41:58 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7654FF25E7; Wed, 6 Jun 2018 11:41:57 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 69E2370786; Wed, 6 Jun 2018 11:41:57 +0000 (UTC) (envelope-from brd@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 46DDF21B84; Wed, 6 Jun 2018 07:41:51 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute5.internal (MEProxy); Wed, 06 Jun 2018 07:41:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=QCJ7Xj G7/uklyA1RRlK/YFJVFdhuh1iWPurqBDJ29Sk=; b=Qge9hV5Q2bj+Qn7fnlAHFs RlSir2E178Vm0gMIhqPM75e+8TS60rC7NnTIM3SnO6bPZhcMMkrcrjENa+MhwsUx JGhYuWxpRFSWGqfXXgYXPf+s+SETfxhDlq33oBuneCijzNKieaK/T5W5Mais2veg 99z1nRfrjfQ2BvFoG6qgrUVqNq5R2lHN7EnrS9ZJtDlpkEO7ubX3dCU0DXfdUaZ9 EOHuggDt+SaOs0sZYSQJ4ASpYlNvtYGRbVXTgi3ykHdB0UQDl2Qixk4xz6evH7F6 JmqRYx8e5N5NvV8S8a2JzMIk7PtpWzt4GCykPs4UNWRh8z6mYbGTyAWuaRvdvkCg == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1272EBA50D; Wed, 6 Jun 2018 07:41:51 -0400 (EDT) Message-Id: <1528285310.3551889.1398315032.22267C9D@webmail.messagingengine.com> From: Brad Davis To: Stefan Esser , Renato Botelho , Konstantin Belousov Cc: "src-committers" , Kyle Evans , svn-src-all@freebsd.org, rgrimes@freebsd.org, svn-src-head@freebsd.org, Alexander Leidinger MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fb4a77ea Date: Wed, 06 Jun 2018 05:41:50 -0600 Subject: Re: svn commit: r334617 - in head: . etc References: <201806041847.w54IlCUu097084@pdx.rh.CN85.dnsmgr.net> <1528138550.3632147.1396107464.614818A8@webmail.messagingengine.com> <20180605150022.Horde.emnJxb8rKYqAvChLgWoX9vf@webmail.leidinger.net> <1528212242.2273706.1397239144.6BEBF1F9@webmail.messagingengine.com> <20180605164627.GM2450@kib.kiev.ua> <1528222385.2736229.1397446048.17853CA8@webmail.messagingengine.com> <20180605182605.GN2450@kib.kiev.ua> <1528231416.2440607.1397619456.294EF898@webmail.messagingengine.com> In-Reply-To: X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 11:41:58 -0000 On Wed, Jun 6, 2018, at 2:25 AM, Stefan Esser wrote: > Am 05.06.18 um 22:43 schrieb Brad Davis: > >=20 > > On Tue, Jun 5, 2018, at 1:07 PM, Renato Botelho wrote: > >> On 05/06/18 15:26, Konstantin Belousov wrote: > >> > On Tue, Jun 05, 2018 at 12:13:05PM -0600, Brad Davis wrote: > >> >> On Tue, Jun 5, 2018, at 10:46 AM, Konstantin Belousov wrote: > >> >>> I find it often very useful to do > >> >>> (cd src/etc/rc.d && make install) > >> >>> Same for defaults and several other directories which in fact cont= ains > >> >>> non-editable content.=C2=A0 Is this planned to keep working ? > >> >> > >> >> The short answer is, no.=C2=A0 All rc.d scripts get moved to the sr= c of the > > program they start. > >> >> > >> >> That said, if there is a big need for this, we can see about option= s to > > keep them working. > >> >> > >> >> What are you trying to accomplish when you do this?=C2=A0 Just veri= fy the rc.d > > scripts match your src tree? > >> > > >> > I avoid mergemaster/etcupdate and whatever else. rc.d and /etc/rc, > >> > /etc/rc.subr /etc/rc.network are not suitable to etc, they are binar= ies > >> > provided by the project not for the user editing. > >> > > >> > When upgrading the host, esp. on HEAD, i usually refresh scripts by = this > >> > procedure and avoid any editing and implied conflict resolution for = real > >> > configs. > >> > > >> > Not being able to easily install clean copies of these scripts would > >> > be very inconvenient and time consuming. > >> > >> If I understood what Brad is saying, each rc.d script will be installed > >> by the application it belongs to. So when it's installing SSH it will > >> also install /etc/rc.d/sshd and you will not need to deal with rc.d > >> files on mergemaster anymore. > >> > >> Is it correct, Brad? > >=20 > > Correct. > I have for a long time (decades?) applied local changes to files in src/e= tc > which (very seldom) may need a conflict resolution, and which make sure t= hat > /etc is populated with files that match my needs. >=20 > It is easy to change a file in /etc until it works as desired and then co= py > it to src/etc, where it is subject to updating via SVN, but still reflects > my preferences. >=20 > With the move to source directories it will be necessary to modify rc fil= es > and other configuration file defaults (e.g. ttys) in a number of places. >=20 > E.g., mergemaster will try to remove the shells installed from ports from > /etc/shells on each run and quite a number of other files will either nev= er > be automatically updated (by excluding them from mergemaster runs) or on > every invocation of mergemaster, unless patched in their respective source > directories spread over the whole source tree. >=20 > This is a BIG step backwards from my PoV, since src/etc currently is the > equivalent of FreeBSD's concept of using /etc/rc.conf for configuration of > all applicable system settings. Having sources of all files that are going > to be installed in /etc (when a new system is setup or by mergemaster) is > equivalent in the sense that the location where changes have to be applied > is confined to just one directory, src/etc (and a few architecture depend= ent > sub-directories). You should really consider moving to etcupdate, as it uses 3-way merge and = make this much easier. Regards, Brad Davis