Date: Wed, 6 Jun 2018 23:27:20 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: rgrimes@FreeBSD.org, Brad Davis <brd@FreeBSD.org>, Eugene Grosbein <eugen@grosbein.net>, Alexander Leidinger <Alexander@leidinger.net>, Kyle Evans <kevans@FreeBSD.org>, src-committers <src-committers@FreeBSD.org>, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r334617 - in head: . etc Message-ID: <20180606202720.GD2450@kib.kiev.ua> In-Reply-To: <1528315608.25377.3.camel@freebsd.org> References: <201806061833.w56IXWBC006288@pdx.rh.CN85.dnsmgr.net> <1528315608.25377.3.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 06, 2018 at 02:06:48PM -0600, Ian Lepore wrote: > On Wed, 2018-06-06 at 11:33 -0700, Rodney W. Grimes wrote: > > > > > > > > > On Tue, Jun 5, 2018, at 1:28 PM, Konstantin Belousov wrote: > > > > > > > > On Wed, Jun 06, 2018 at 01:39:00AM +0700, Eugene Grosbein wrote: > > > > > > > > > > 06.06.2018 1:26, 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 > > > > > > > > contains> > >>> non-editable content.ššIs this planned to > > > > > > > > keep working ? > > > > > > > The short answer is, no.ššAll rc.d scripts get moved to the > > > > > > > src > > > > > > > of the program they start.> > >> > > > > > > > That said, if there is a big need for this, we can see > > > > > > > about > > > > > > > options to keep them working.> > >> > > > > > > > What are you trying to accomplish when you do this?ššJust > > > > > > > verify > > > > > > > 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 > > > > > > binaries> > > 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. > > > > > I found that "mergemaster -iFUP" deals with unchanged files > > > > > including mentioned rc* scripts just fine.> > That is, it > > > > > automatically refreshes unchanged files without any > > > > > silly questions just for change of $FreeBSD$.> > > > > No, you missed the point.ššWhatever nice is the handling of > > > > unchanged files,> use of mergemaster forces me to handle changed > > > > files, which is exactly> what I do not want/need to do.ššYes, I > > > > update crashboxes very > > > > often, and> I want to get all new code, including the startup > > > > scripts, when > > > > I update. > > > The startup scripts will be installed as part of installworld. > > So each installworld would wipe over the top of any localmod > > /etc/rc.d/ and other stuff > > that mght exist? > > One of the reasons that etc/Makefile is detached from Installword is > > so that > > /etc does not get perturbuted unless specifically requested. > > > > I don't understand the drama over this.ššrc.d startup scripts are > *binaries*. Users are not expected to modify the system installed > binaries, and if they do, it is expected that the next installworld > will replace them with the system binaries again. I agree with this, but the scripts are installed into /etc. I proposed to move them somewhere, e.g. to /sbin/rc* or to /libexec/rc*. If moved first, then the proposed change would be much more logical and probably easier to fit into the workflows of FreeBSD consumers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180606202720.GD2450>