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