From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 08:29:56 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 68921106566B for ; Mon, 5 Dec 2011 08:29:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3ED7B8FC13 for ; Mon, 5 Dec 2011 08:29:56 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pB58Tqxe093386 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 00:29:54 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EDC810F.8060902@freebsd.org> Date: Mon, 05 Dec 2011 00:30:07 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: Daniel Eischen 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> <029322CC-FFF0-4DE2-8ABE-2AF2F2345906@vigrid.com> In-Reply-To: <029322CC-FFF0-4DE2-8ABE-2AF2F2345906@vigrid.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 08:29:56 -0000 On 12/4/11 9:21 PM, Daniel Eischen wrote: > 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=YES 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? >>> >>> but let's get concrete here. >>> >>> 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 >>> >>> and then do whatever is special for this particular system. >>> >>> 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. >> 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. >> >> They have pre-installed entries in /etc/defaults/rc.conf. and only their rc,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 of the stuff, >> and it allows them to easily be 'deinstalled' and replaced by newer versions. > I really don't understand how this is much different than having them exist in 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 ports 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 bug fixes throughout all updates to -stable, not just at releases. > > I want to do one buildworld and have a complete and integrated system. I don't see how having a separate repo for sysports helps; it is yet another thing I have to track. And are ports in sysports going to default to being installed in / or /usr/local? I think there are several differences.. 1/ The ability to UNINSTALL it and replace it completely with a differnet version 2/ allow easy leave-out feature.. leaving it out is less risky.. 3/ probably the most important.. allowing both ports and src developers to work on the packages. 4/ allowing us to promote some of the commonly used packages to a more supported level without actually bringing them into the base system. > -- > DE >