From owner-freebsd-pkgbase@freebsd.org Tue Apr 19 01:24:19 2016 Return-Path: Delivered-To: freebsd-pkgbase@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 351FDB14519; Tue, 19 Apr 2016 01:24:19 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orthanc.ca", Issuer "Let's Encrypt Authority X1" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 209BA1EE2; Tue, 19 Apr 2016 01:24:19 +0000 (UTC) (envelope-from lyndon@orthanc.ca) Received: from minnie.bitsea.ca ([24.114.43.34]) (authenticated bits=0) by orthanc.ca (8.15.2/8.15.2) with ESMTPSA id u3J1OHaT053841 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Apr 2016 18:24:18 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Subject: Re: [CFT] packaging the base system with pkg(8) References: <20160302235429.GD75641@FreeBSD.org> <57152CE5.5050500@FreeBSD.org> <9D4B9C8B-41D7-42BC-B436-D23EFFF60261@ixsystems.com> <20160418191425.GW1554@FreeBSD.org> <571533B8.6090109@freebsd.org> <20160418194010.GX1554@FreeBSD.org> <57153E80.4080800@FreeBSD.org> <571551AB.4070203@freebsd.org> <5715772A.3070306@freebsd.org> To: freebsd-pkgbase@freebsd.org, freebsd-current@freebsd.org From: Lyndon Nerenberg Message-ID: <571588BB.2070803@orthanc.ca> Date: Mon, 18 Apr 2016 18:24:11 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5715772A.3070306@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-pkgbase@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Packaging the FreeBSD base system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 01:24:19 -0000 On 2016-04-18 5:09 PM, Nathan Whitehorn wrote: > I'm not so sure about these statements. Maintaining groups of packages > can be easier, but it can be also be harder. The goal is to find the > right level. And I haven't seen a case where an 800-packages level of > granularity is helpful. Not to mention regression testing. The number of combinations of installed packages is going to be choose(1, 800) + chose(2, 800) + ... + choose(800, 800). And while some of those combinations will be non-nonsensical, many(!) won't. There aren't enough seconds in the universe to test all the viable combinations for one single release. If fact, I would suggest a good metric for package granularity be based on the set of combinations that *can* be tested in a realistic timeframe for each release. --lyndon