From owner-freebsd-arch@freebsd.org Sat Aug 4 16:51:41 2018 Return-Path: Delivered-To: freebsd-arch@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 2B08310707D4; Sat, 4 Aug 2018 16:51:41 +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 C64B77F833; Sat, 4 Aug 2018 16:51:40 +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 7A8002144B; Sat, 4 Aug 2018 12:51:40 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute5.internal (MEProxy); Sat, 04 Aug 2018 12:51:40 -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=fm3; bh=kejvDg kH0es35doQ1Hhed/u85N/efG/IzSwDACSSHPg=; b=QoJKzIPEVOpA5/HoonCyzj BU/weMfLT2a4C37qiiZRuDTBLoMMlmi1h2rgCil8wAIzOgLnb0Js9e+PK64raG8P lC/K0tUL8r5Xy3q5MNLWyJ3TxWSTNdsiNHPuzFQPdrAi+MdAi19mUMxN+8iusNWu cAnogR9an211vHBSrkTI3YrwQnmZbk4N3cxTNRCnXveX3kLqHseWJap8EI3L3Zcx Z2m22LKabKMV0nPDuU+T0+AK80u1Be7KHCJf9wSU4PjOWi16mNDJhTHsxQJkr3lt e2rI1pWPGdFnZPMiIk/kkdpPF8QBIgTQKlAnO9pI1K+z1cA3McCUbjME5PlHg50w == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id F04DB4143; Sat, 4 Aug 2018 12:51:39 -0400 (EDT) Message-Id: <1533401499.1192219.1463428312.4AE8091D@webmail.messagingengine.com> From: Brad Davis To: Chris H , freebsd-pkgbase@freebsd.org Cc: freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-2be8cd1b In-Reply-To: <9e28add9809e7d19c3b0d14880df62d8@udns.ultimatedns.net> Date: Sat, 04 Aug 2018 10:51:39 -0600 Subject: Re: pkgbase: Move of head/etc/ files References: <9e28add9809e7d19c3b0d14880df62d8@udns.ultimatedns.net> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2018 16:51:41 -0000 On Sat, Aug 4, 2018, at 3:43 AM, Chris H wrote: > On Wed, 01 Aug 2018 17:54:10 -0600 "Brad Davis" said > > > Hello, > > > > I want to give some information on what is happening to files in head/etc/ > > and open a discussion. > > > > I am trying to move all config files out of head/etc/ and place them with the > > source files for the particular use. For example, some of these are obvious > > moves like moving say portsnap.conf to usr.sbin/portsnap/portsnap.conf. The > > review for this move shows exactly what would happen here: > > https://reviews.freebsd.org/D16554. For these cases, there are some easy > > benefits, like: > > 1) Keeping all files as part of a program together, which makes maintenance > > for maintainers a little easier. > > 2) Simplicity, we do not need all the .if ${MK_FOO} lines in etc/Makefile > > because that is handled a level above the programs Makefile and so one CONFS= > > line is all that is needed. > > 3) Easier to avoid bugs where we install things that should not be installed. > > Like for apmd, we installed apmd.conf on all archs even though it only works > > on i386. i.e. we don't have to keep knobs in sync in multiple locations. > > > > Some of the more complicated things to move like etc/shells and the init > > scripts. I picked the location of etc/shells based on it being used by > > getusershell(3) in libc, so it ended up in lib/libc/gen/shells. The move of > > the init scripts was based on a few things, including the reasons above, but > > additionally: > > 1) Isolating a subcomponent, for example work is happening to bring in > > OpenRC, so we will have multiple init systems with different types of > > scripts, so moving them away from head/etc/ keeps them isolated. > > Is the current rc(8) broken? Is OpenRC an intended replacement? How is this > going to work? I am not sure what the status or progress is for this. Probably worth contacting Kris Moore. Regards, Brad Davis