From owner-svn-src-projects@freebsd.org Mon Feb 8 15:30:15 2016 Return-Path: Delivered-To: svn-src-projects@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 C656EAA1724 for ; Mon, 8 Feb 2016 15:30:15 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0C2C66B; Mon, 8 Feb 2016 15:30:15 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u18FU7gx011886 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Feb 2016 07:30:07 -0800 Subject: Re: svn commit: r295280 - projects/release-pkg/release/packages To: Glen Barber References: <201602042120.u14LKQ2b026571@repo.freebsd.org> <56B3C34B.1080501@freebsd.org> <56B3C6E4.60907@FreeBSD.org> <56B3C7A3.5000502@FreeBSD.org> <56B3EF97.9040205@freebsd.org> <20160205005113.GD13799@FreeBSD.org> <56B3F5A2.7070600@freebsd.org> <20160205013040.GG13799@FreeBSD.org> <56B82697.4090800@freebsd.org> <20160208111726.GD63576@FreeBSD.org> Cc: svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org, Bryan Drewery From: Nathan Whitehorn Message-ID: <56B8B47F.7060001@freebsd.org> Date: Mon, 8 Feb 2016 07:30:07 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160208111726.GD63576@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaGQ6p8w1i4R3I/ziWOnN7paHYvGMxhwMXrBo6Qr9iIzAmUgDScV1pMxNNqJjVRY/hmUUw3k0ZJiVyzR/N4IXu1/XX45ApSQ/Q= X-Sonic-ID: C;RAMZ1XjO5RGU4sEl14k5kQ== M;ykJx1XjO5RGU4sEl14k5kQ== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 15:30:16 -0000 On 02/08/16 03:17, Glen Barber wrote: > On Sun, Feb 07, 2016 at 09:24:39PM -0800, Nathan Whitehorn wrote: >> Thank you very much for the overview! I had a couple of questions inline, >> but please feel free to answer them at your leisure. >> >> On 02/04/16 17:30, Glen Barber wrote: >>>> Maybe I missed them? The talks I've seen (e.g. >>>> https://www.bsdcan.org/2015/schedule/events/563.en.html) describe some >>>> technical problems, the idea that pkg is nicer than freebsd-update (true >>>> enough), and that having some more granularity (bind and sendmail separated >>>> out, for instance) in installation would be a good thing. That all sounds >>>> perfectly reasonable and good, but is also pretty nebulous. >>>> >>>> It would be good have something a little more detailed on what a packaged >>>> base system actually looks like: what kinds of things would constitute a >>>> package? >>> Short answer: A set of binaries and libraries upon which the binaries >>> require to run. >> So would this imply that, say, ls would be its own package? Or that we would >> have something less granular (so that things like sendmail would be a >> package)? It seems like this is something still in flux, so there may not be >> an answer yet. >> > There is no easy way to answer this, because WITH_*/WITHOUT_* knobs are > being taken into account. > > As I see things now, everything in bin/ and sbin/ would be included in > the main, default package unless there is a MK_*=no test in the build. > Those would be split into a separate package. > > So no, ls(1) is not expected to be in its own package, but sendmail(8) > is. That makes sense. Thanks! >>>> are those packages (e.g. for sendmail) interchangeable with ones >>> >from ports? >>> Separate package repositories. Separate package naming scheme. >>> Completely independent. >>> >>>> would the pkg tool be imported into base? >>> No. >> Doesn't this complicate the installer tremendously? The install ISOs would >> need pkg on them and couldn't be built only from the base system anymore. > Yes, this is still being worked out. This should be solvable with > a tmpfs(5) /usr/local mount on the ISO, however we cannot enforce > a network connection to bootstrap pkg(8). An option is to include > pkg(8) as part of the on-disc repository itself. > > There multiple additional layers of "how are we going to [...]" that > tail off of this alone. > > Glen > That is indeed a puzzler. Something to think about as we move closer to having this in the tree, I guess. -Nathan