CFT: FreeBSD Package Base
Matthew Seaman
matthew at FreeBSD.org
Thu May 2 11:58:10 UTC 2019
On 30/04/2019 09:22, David Chisnall wrote:
> On 29/04/2019 21:12, Joe Maloney wrote:
>> With CFT version you chose to build, and package individual components
>> such as sendmail with a port option. That does entirely solve the
>> problem of being able to reinstall sendmail after the fact without a
>> rebuild of the userland (base) port but perhaps base flavors could
>> solve that problem assuming flavors could extend beyond python.
>
> This sounds very much like local optimisation. It's now easy to create a
> custom base image. Great. But how do I express dependencies in ports
> on a specific base configuration? This is easy if I depend on a specific
> base package, but how does this work in your model? For example, if I
> have a package that depends on a library that is an optional part of the
> base system, how do I express that pkg needs to either refuse to install
> it, or install a userland pkg that includes that library in place of my
> existing version as part of the install process?
In principle, this should be covered by the 'provides - requires'
functionality in pkg. However at the moment this is limited to just
analysing binaries to find what shared libraries they load.
There's an arbitrary removal of any base-system shlibs from the
provides/requires in the standard port packages built today, but that
can be overridden by setting ALLOW_BASE_SHLIBS in pkg.conf.
We'd need to add quite a lot of new metadata to packages to fully
express all of the things they provide that another package could
require -- anything from a high-level concept like 'I need a webserver:
anything will do' down to something as specific as 'I need to have
exactly this specific file installed.' Some of that can be
automatically generated at package build time, but a lot of it will
require maintainers to manually add settings.
We'd also need to ensure that both the ports tree and pkg(8) handle
alternate dependencies correctly. A lot of the effort in maintaining
the ports at the moment goes towards generating a self-consistent set of
packages with a single dependency inheritance (albeit one that can be
switched by changing some flags and recompiling -- eg. to swap between
openssl and libressl) Flavourization is one step towards this, but by
no means a complete solution.
Cheers,
Matthew
More information about the freebsd-hackers
mailing list