From owner-freebsd-pkgbase@freebsd.org Tue Apr 19 13:54:39 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 1B142B14B27 for ; Tue, 19 Apr 2016 13:54:39 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9834C144D for ; Tue, 19 Apr 2016 13:54:38 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from zero-gravitas.local (unknown [85.199.232.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id A9EED110B2 for ; Tue, 19 Apr 2016 13:54:33 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/A9EED110B2; dkim=none; dkim-atps=neutral Subject: Re: [CFT] packaging the base system with pkg(8) To: freebsd-pkgbase@freebsd.org 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> <5715E1E9.8060507@freebsd.org> From: Matthew Seaman Message-ID: <571638B9.6020904@FreeBSD.org> Date: Tue, 19 Apr 2016 14:55:05 +0100 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: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xvDNbrOug7QtN1jE6DMjWguGMEARtNtat" X-Virus-Scanned: clamav-milter 0.99.1 at smtp.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,RDNS_NONE, SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk 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 13:54:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xvDNbrOug7QtN1jE6DMjWguGMEARtNtat Content-Type: multipart/mixed; boundary="gK3hsJdxn4HHx6pI73L7VsEcfCcHUFEVn" From: Matthew Seaman To: freebsd-pkgbase@freebsd.org Message-ID: <571638B9.6020904@FreeBSD.org> 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> <5715E1E9.8060507@freebsd.org> In-Reply-To: --gK3hsJdxn4HHx6pI73L7VsEcfCcHUFEVn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2016/04/19 08:54, David Chisnall wrote: > The big advantage of going with small packages initially, however, is > that it will allow us to get some data on what the correct groupings > are. If we have large packages, then it=E2=80=99s very hard to tell wh= ich > subsets of the packages people want. That=E2=80=99s exactly the situat= ion > that we=E2=80=99re in now: we know some people don=E2=80=99t want docs = or games, but > that=E2=80=99s about all that we know. It=E2=80=99s easy to move to a = model where we > have *fewer* packages in the future, but it=E2=80=99s harder to split t= hem. > That also applies to dependencies. If I know that a port depends on > the shell, then it=E2=80=99s easy to update it from depending on a sh p= ackage > to depending on a core system utilities package automatically, but > it=E2=80=99s very hard to do an automatic update in the other direction= =2E Exactly. Bapt's talks[+] about the design decisions behind how base was divided up into packages explain very clearly why the situation now is as it is. Basically *any* way of dividing up the base system into packages would raise the hackles of some subset of the user base. So he chose to create a large number of small packages for maximum flexibility and also supply a range of different meta-packages allowing installation of various useful package sets as a simple operation. The current base package builds don't actually include those meta-packages yet, so it's impossible to say right now how that will work out. Yes, this is the first attempt at creating a package hierarchy for base, and it's going to be buggy. The way things are set up should mean that those bugs are only annoyances, and not show stoppers. Complaining purely about the /number/ of packages the base is divided into is not productive: certainly there are some packages that could be merged or otherwise eliminated, but until people come up with concrete proposals about the details of doing that, little progress is going to be made. Yes, I agree that the way pkg(8) displays the package data certainly could be improved. The base packaging setup actually implements a idea we have been talking about with reference to the ports tree: that is 'sub-packages.'[*] What's missing is a neat way of displaying and handling a package that consists of a collection of sub-packages; at the moment they're all shown as completely independent packages, which works as far as the mechanics of installing and maintaining your server but doesn't necessarily give the best user experience. Cheers, Matthew [+] https://youtu.be/Br6izhH5P1I?list=3DPLWW0CjV-TafY0NqFDvD4k31CtnX-CGn8= f [*] So that one port could compile into several different packages, including separate pkg blobs for docs, examples, shared libraries, debugging symbols, C/C++ header files, various different extras enabled by options settings and (not least) the actual program binaries or scripts. By default you'ld get all of the above simply by installing the top-level package -- which would result in the same filesystem content as when using the existing monolithic packages. However you could install or delete any of those sub-packages separately as required. Means, for instance, you could install multiple different ABI versions of a shared library simultaneously, something you can't do nicely with either ports or packages today unless there's some special hack to allow it. --gK3hsJdxn4HHx6pI73L7VsEcfCcHUFEVn-- --xvDNbrOug7QtN1jE6DMjWguGMEARtNtat Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJ8BAEBCgBmBQJXFji/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxOUYxNTRFQ0JGMTEyRTUwNTQ0RTNGMzAw MDUxM0YxMEUwQTlFNEU3AAoJEABRPxDgqeTnfMoQAJqMApO6l+DvwYDmBMADsWbL mSJhVY7/d/p0t7E3laKIlBa7AWxqeNy7h/0PwbK/s3h3H0YdbvmIj3PCM1oAQyBW nqopo4j4KA5/0PwptQ8pjs/Hv2P0B9Oj8htWKgHsfuRLO8h7L3dBNF/tp/lhCzCf vyIiq0AM7H1eJVcxpQYnEfBoPrt5H/518HSGUUgBqL2HvYGnojF/veg3ywqxZ/bg pjay2S0nGeoxI3xDIphOICXqIIDp4mljoq0e4TJT0E6Fr6MJCh2J95fMe3AwjjFR 7Rr5DZdrvvRK1TVYPPd/yHYN8bB00pCGWG005zmqZcKhwrkkxDG66gkbr6hJ5cc1 s13yXhV3BEusKDtNMUFMTiO40UL4b/VM/RK8a+PDN4V8KqbqT3gCkYW4oGccpeLw uLsXqrMlyC320Lkoz0eOIwtTU0NmrnjN3AGkbNa2jFUXzqO4KNj/FRmhoKlsffya GIpzd3L+jQSQ0aKYU+PADFM7MS8c+D4vWbx+H0nwoO9IjPXSwFJ0yQciD2ndzB2g punL27HC98Ss5f+1uVTATiu1H2eZUt2RtYEGgl6YPDBDt375eQS3dOdDY3ESNH44 Cfrg7iXmtArmmvp0YYli0gu2twrGiLdQR7mcY5vyIusWfPIvOcoOuMOcMitPacwc 3HglCT13EVwAy/6DanjF =Lnux -----END PGP SIGNATURE----- --xvDNbrOug7QtN1jE6DMjWguGMEARtNtat--