From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 05:44:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C211065708; Mon, 5 Dec 2011 05:44:14 +0000 (UTC) (envelope-from eischen@vigrid.com) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 3BC4A8FC0C; Mon, 5 Dec 2011 05:44:07 +0000 (UTC) Received: from [10.0.0.52] (ip-414b102e.ct.fixed.ntplx.com [65.75.16.46]) (authenticated bits=0) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pB55LcX6052250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Dec 2011 00:21:38 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Mon, 05 Dec 2011 00:21:38 -0500 (EST) References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> <4EDC135C.5000400@freebsd.org> In-Reply-To: <4EDC135C.5000400@freebsd.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <029322CC-FFF0-4DE2-8ABE-2AF2F2345906@vigrid.com> X-Mailer: iPhone Mail (9A405) From: Daniel Eischen Date: Mon, 5 Dec 2011 00:21:37 -0500 To: Julian Elischer Cc: Randy Bush , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 05:44:14 -0000 On Dec 4, 2011, at 7:42 PM, Julian Elischer wrote: > On 12/4/11 3:36 PM, Randy Bush wrote: >>> This seems too reasonable a suggestion, but, as always, the devil >>> is in the details. There will be long. painful discussions (and >>> arguments) about what to remove from the base to the new structure >>> and what things currently NOT in the base should be promoted. >> as one with a long list of WITHOUT_foo=3DYES in /etc/src.conf, this is >> tempting. but, as you hint, is this not just doubling the number of >> borders over which we can argue? >>=20 >> but let's get concrete here. >>=20 >> i suspect that my install pattern is similar to others >> o custom install so i can split filesystems the way i prefer, >> enabling net& ssh >> o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer >> if it does not have emacs) >> o hack /etc/ssh/sshd_conf to allow root with password >> o rsync over ~root >> o hack /etc/ssh/sshd_conf to allow root only without-password >> o rsync over my standard /etc/foo (incl make.conf and src.conf) >> and other gunk >> o csup releng_X kernel, world, doc, ports >> o build and install kernel and world >>=20 >> and then do whatever is special for this particular system. >>=20 >> anything which would lessen/simplify the above would be much >> appreciated. anything not totally obiously wonderful which would >> increase/complicate the above would not be appreciated. >=20 > my suggestion is that the 'sysports' or 'foundation ports' or > 'basic ports', (or whatever you want to call them) in their package > form come with the standard install in fact I'd suggest that they > get installed into some directory by default so that 'enabling' them > ata later time doesn't even have to fetch them to do the pkg_add. >=20 > They have pre-installed entries in /etc/defaults/rc.conf. and only their r= c,d > files need to beinstalled into /etc along with their program files. > They are as close to being as they are now with the exception of > being installed in the final step instead of at the same time as the rest o= f the stuff, > and it allows them to easily be 'deinstalled' and replaced by newer versio= ns. I really don't understand how this is much different than having them exist i= n base. We have WITHOU_foo (I don't really care if that were to become WITH= _foo if we want to default to a more minimum system), so one can always use p= orts if they want some different version of foo. And it's not just releases= we care about, we want a stable foo (BIND for example) with security and bu= g fixes throughout all updates to -stable, not just at releases. I want to do one buildworld and have a complete and integrated system. I do= n't see how having a separate repo for sysports helps; it is yet another thi= ng I have to track. And are ports in sysports going to default to being ins= talled in / or /usr/local? -- DE=