Date: Wed, 12 Oct 2016 07:55:27 +0100 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-ports@freebsd.org Subject: Re: harder and harder to avoid pkg Message-ID: <29bf92f3-994f-e695-431a-dc73a3f9c19d@FreeBSD.org> In-Reply-To: <638fe078-80db-2492-90be-f1280eb8d445@freebsd.org> References: <638fe078-80db-2492-90be-f1280eb8d445@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--oA8d47btWRo25uVQxp37CSOkT4G2iXPj5
Content-Type: multipart/mixed; boundary="IWr5lU81aI9n0mpD4k6ULwWWnV3oSsKoA";
protected-headers="v1"
From: Matthew Seaman <matthew@FreeBSD.org>
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29bf92f3-994f-e695-431a-dc73a3f9c19d>