From owner-svn-src-projects@freebsd.org Fri Feb 5 00:51:16 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 1F051A9CDAD for ; Fri, 5 Feb 2016 00:51:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 10D8515C1; Fri, 5 Feb 2016 00:51:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 665581929; Fri, 5 Feb 2016 00:51:15 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Fri, 5 Feb 2016 00:51:13 +0000 From: Glen Barber To: Nathan Whitehorn Cc: Bryan Drewery , src-committers@FreeBSD.org, svn-src-projects@FreeBSD.org Subject: Re: svn commit: r295280 - projects/release-pkg/release/packages Message-ID: <20160205005113.GD13799@FreeBSD.org> References: <201602042120.u14LKQ2b026571@repo.freebsd.org> <56B3C34B.1080501@freebsd.org> <56B3C6E4.60907@FreeBSD.org> <56B3C7A3.5000502@FreeBSD.org> <56B3EF97.9040205@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d01dLTUuW90fS44H" Content-Disposition: inline In-Reply-To: <56B3EF97.9040205@freebsd.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) 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: Fri, 05 Feb 2016 00:51:16 -0000 --d01dLTUuW90fS44H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 04, 2016 at 04:40:55PM -0800, Nathan Whitehorn wrote: > >>>Are we really planning to split up the system at this level of > >>>granularity? That seems like a huge regression from one of the main > >>>selling points of FreeBSD: that it is *not* split up at this level and > >>>forms a unified system. > >>>-Nathan > >>> > >>You are jumping to conclusions. Splitting how files are *tracked in > >>metadata* changes nothing about what we are delivering in a release. > >> > >>What level does freebsd-update track the system? It seems it is per-fil= e. > >> > >>This constant idea that splitting files in metadata is bad is hindering > >>progress greatly. > >> > >Also, pkg has no binary diff packages. The plan to release 11 with > >packages is moving forward. Do we really want a multi-gigabyte world > >package being downloaded so we can modify a security bug in > >/etc/rc.d/jail? It makes no sense. > > > >This commit in particular is wrong in that it does not go *far enough*. > >Everything installed needs to be handled by dependency ordering. > > > >The resistance to doing this correctly needs to just stop or we're going > >to end up with a completely broken system. > > >=20 > My question, which you did not quite answer, was in how many packages the > FreeBSD base system will be delivered. I didn't have any conclusions, sin= ce > I don't know anything about what is happening. However the metadata is > organized is fine, though I do worry that this level of > per-library/-binary/-whatever manual dependency tracking may quickly beco= me > stale and will raise the barrier to adding new libraries. >=20 > But that doesn't really matter. The general worry, which has been express= ed > by others and never to my knowledge addressed, is that: > 1) Splitting the base system into 1000 packages will make it easier to not > have some of those packages. This would destroy one of the absolute best > things about the operating system: that "FreeBSD 10.2" is a coherent thing > and all of the tools that make it up can be relied on to exist. The earli= er > version of "packaging base" that I heard about would have a handful (mayb= e 5 > or 6) packages similar to the granularity that the installer and > freebsd-update use, which is an easy enough thing to handful. Splitting the base system into packages reinstates granular installation ability, which was present in 8.x and prior releases. Based on many reactions to this, a 'feature' not a 'bug.' > 2) Having that split makes it easier to have mismatched versions. This is= a > problem I have encountered often on Linux distributions that blend third- > and first-party software or have the 1000-package base system concept and > that I encounter all the time with ports. Having a reliable, monolithic b= ase > system that is guaranteed to be internally consistent is *tremendously* > valuable. >=20 This is why the work is being done in a *project* branch, not head. > Would it be possible to have some summary of what the plan for "packaging > base" actually is? I'm sure these are things that have been thought about, > but it's been difficult for me at least to follow what is going on. Just > some kind of white paper would be really helpful, or, at the very least, a > few paragraphs in the quarterly status report to give a view from 10k fee= t. This, honestly, has been asked repeatedly, and provided answers. Both to PDFs of talks, URLs to talks being recorded, etc. Here's the bigger problem, from my view, as things stand now: there was no mystery that packaged base system was going to be targeted for 11.0-RELEASE. Progress slowed for a while, and has since resumed. Now, that it has been stated that it is *required* for 11.0-RELEASE, people are pointing out problems or requesting things for items noted in both, the PDFs and URLs mentioned above, and nitpicking on things that either are not relevant (meaning, does not exist) or things that we know will be required for this to work. This is a project branch. I'm making an omelet, and all of the commits until this is merged back to head are sacrificial eggs, no matter what the end result of what 11.0-RELEASE looks like. Glen --d01dLTUuW90fS44H Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWs/IBAAoJEAMUWKVHj+KTwdQP/R2+ihMkfA311fyuIRyPeKqS NdkWK+BvB9AV1csGdbCT0kU9PEWceiq88UF/CZ25LYbCXtg8XBc36JjddhBccFzs xz3WTVsGrt+U7ktwlTecDQNIi3Zrn+TYxK3C1Ic2bKDbAVcHf6mrXWaZ9cpAOtiO 3lczZQtUHukwphtxIN/mqCKI1ti2TwSdH7JnWcfdTY4eunZoHTQedZLGUdwa4fpw rBQiK6enHaV56VpwdbKSIUbeKYBHw2Bj42+XrhnJ6mDg4zZP+AYAo7OUgOFwUoGq BVpq15rv3RA9pA0pN4J1mCseiNsvG/dpNfgkiabZun74cSD0ccySVCERLQ1qexx3 Ep38mYPgGZq0IKVa3znsYDq2cqFO68/XFP2V1yFhZuoA4od6cypAQ66Elph2DiMt aPdzMAskH7lbg2rRsWKJeytH30JYQaq73fqXqezpQZT/Z7IGQTdVefYgM38s6kiw f6DCYH4D7BsE4IniZE3bWV3FReve5u8HBvBtxjYcx4OUKF97i1BzVS9Gmy2v9oeN j+eoftZwPr/zjRa4cEnS9zz49qG0hRFwVxruznjT8mn518qNal/qITu4E7JtohiQ o2kKSyjFRi+XjtKvmF+0su24vslR/QOoBvfLxnvUhKnji57YrNd2JEV4+TF9kGB5 w1HoUw3um4jy6qvM2xG/ =FymZ -----END PGP SIGNATURE----- --d01dLTUuW90fS44H--