From owner-freebsd-ports@freebsd.org Wed Oct 12 06:55:42 2016 Return-Path: Delivered-To: freebsd-ports@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 00796C0EC09 for ; Wed, 12 Oct 2016 06:55:42 +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 CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8227E1C8 for ; Wed, 12 Oct 2016 06:55:41 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from liminal.local (unknown [IPv6:2001:8b0:151:1:1c1d:86a1:a200:b700]) (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 D483FA5F9 for ; Wed, 12 Oct 2016 06:55:35 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/D483FA5F9; dkim=none; dkim-atps=neutral Subject: Re: harder and harder to avoid pkg To: freebsd-ports@freebsd.org References: <638fe078-80db-2492-90be-f1280eb8d445@freebsd.org> From: Matthew Seaman Message-ID: <29bf92f3-994f-e695-431a-dc73a3f9c19d@FreeBSD.org> Date: Wed, 12 Oct 2016 07:55:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <638fe078-80db-2492-90be-f1280eb8d445@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oA8d47btWRo25uVQxp37CSOkT4G2iXPj5" 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-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 06:55:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oA8d47btWRo25uVQxp37CSOkT4G2iXPj5 Content-Type: multipart/mixed; boundary="IWr5lU81aI9n0mpD4k6ULwWWnV3oSsKoA"; protected-headers="v1" From: Matthew Seaman To: freebsd-ports@freebsd.org Message-ID: <29bf92f3-994f-e695-431a-dc73a3f9c19d@FreeBSD.org> Subject: Re: harder and harder to avoid pkg References: <638fe078-80db-2492-90be-f1280eb8d445@freebsd.org> In-Reply-To: <638fe078-80db-2492-90be-f1280eb8d445@freebsd.org> --IWr5lU81aI9n0mpD4k6ULwWWnV3oSsKoA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/10/2016 19:59, Julian Elischer wrote: > As the number of dependencies between packages get ever higher, it > becomes more and more difficult to compile packages and the dependence > on binary precompiled packages is increased. However binary packages ar= e > unsuitable for some situations. We really need to follow the lead of > some of the Linux groups and have -runtime and -devel versions of > packages, OR we what woudlbe smarter, woudl be to have several "sub > manifests" to allow unpacking in different environments. >=20 >=20 > A simple example: libxml2 >=20 > This package installs include files and libraries and dicumentation etc= =2E >=20 > yet if I build an appliance , I want it to only install a singe file. >=20 > /usr/local/lib/libxml2.so.2 >=20 >=20 > The presence of this file will satisfy any runtime dependencies of > packages that require it. >=20 > Unfortunately there is no way to install just this file, and still > report that we have the package loaded, so >=20 > pkg will always try to reinstall it leading to a huge mess. >=20 > My current scheme is to unpack all packages into a larger staging area,= > and *manually* (scripted) copy out only the files I need, and then copy= > the pkg database, so that when run on the running appliance, pkg THINKS= > all the packages are loaded on the appliance, even though only the > runtime files are installed. This is what we in the industry call "a > hack" :-) It is also not robust in the face of changing pkg versions. >=20 > It would be a lot better it pkg knew it was being asked to install only= > the runtime set, and coudl accurately store this information in its > database, allowing it to satisfy the needs of other packages that need > that dependnency only in a runtime manner. >=20 > Is any of this possible at the moment? >=20 > suggestions from the ports/pkg community are appreciated.. >=20 > Julian You are describing the 'sub-packages' concept that has been knocking around for some time. With sub-packages you'ld divide up the result of staging each port into various chunks: - binaries + config file samples + required data files (the core pkg content) - shlibs - debug symbols - docs - examples - c/c++ headers and static or profiling libs (ie. only required for compilation) - various additional plugins etc. currently controlled by port options Each of these would be packaged separately and can be used independently for resolving dependencies. Building each port would result in as many of these sub packages as are applicable. Turning OPTIONS into sub-packages will also significantly reduce the number of OPTIONS settings needed in the ports tree (I think bapt had an estimate of about a 70% reduction but ICBW) and make the pkg system significantly better able to handle more varied user requirements without users having to compile their own packages. Unfortunately attention has been diverted while there's a lot of work going on towards packaging base. The problem as far as ports are concerned is producing several packages out of one port -- it's not rocket science level of difficulty to make that change, but the assumption of a one-to-one correspondence between ports and packages is deeply rooted, and it's going to take a lot of work to unpick. Happily, the package sets produced for the base system are already divided along these lines, so with a packaged base it is really very easy to produce a stripped down and streamlined base system. Cheers, Matthew --IWr5lU81aI9n0mpD4k6ULwWWnV3oSsKoA-- --oA8d47btWRo25uVQxp37CSOkT4G2iXPj5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJX/d5nXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATSPQP/264kaZeguD6pXHT4DjMVDdV KFrNxH5yKCGeV9JskN0is5Dc4pql/51PunOH5maCWFq1+wBzq3yWMHwWvhhG+DjD WgWTwWh9V72NVWMclKwqZJzMJLNykXb757lHBD7rqUAsUDcMemodja7fwfxcSF5K VrsvN5UniRPoZErqFn/RX7yOAm1ik4jh9EEEALqbWm0ZU581bl8RhK6/f8bMiKzF NXjf3pXCv+OjlmKRW0En4815gC346zDrPRLUq3Gk1+b7z8UMo/7YEXn256129m1K eKKOOeR/N/PElJwWnYzJCcdg5IYCfiVQr1foPJOqZ4YLc7S0dgRWGBcD2gyEt3F4 5qlknu4ksoWLx/6yRYd0JSpciWYTveX+fOlkVKKNlyl3eyxSjpsG/3238KXQn4d2 4rkb/JWevfUet11H4i4Ry8qaKP55IEiC6SqP6GuCGJTu0Oe2V+xfV4QZMx3qfvtL g43TX+Vy33M9DfmFi66X10DkQf0dHgpGaB18wBto1n4k7ByhkQgic9anWsZTG1UL kEnLVcJhHVtpLXw+NzYAcq5A0G4MoCDktYxNSNG4zDmR8wY6Jsgq8OuIx77Vin8j 0coddnjOR6NjVhqJI4mzzJpLgL5jHeCXnYX2QGbI7V55ttrSvMoKzCM/nhawIE1r VL1Yxu6O5BWOZXESlick =Upnh -----END PGP SIGNATURE----- --oA8d47btWRo25uVQxp37CSOkT4G2iXPj5--