Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 May 2019 12:58:04 +0100
From:      Matthew Seaman <matthew@FreeBSD.org>
To:        freebsd-hackers@freebsd.org
Subject:   Re: CFT: FreeBSD Package Base
Message-ID:  <e8e49088-a103-591f-7a10-8e34312dd986@FreeBSD.org>
In-Reply-To: <daecd304-d4f6-7b15-3455-6a3b734cb258@FreeBSD.org>
References:  <201904291931.x3TJV73d079802@slippy.cwsent.com> <6EB65F49-47CD-48B2-8C58-BF387D8C7A58@ixsystems.com> <daecd304-d4f6-7b15-3455-6a3b734cb258@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e8e49088-a103-591f-7a10-8e34312dd986>