Re: CFT: FreeBSD Package Base

On 2019-04-30 17:03, Miroslav Lachman wrote:
> David Chisnall wrote on 2019/04/30 10:22:
>> 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?
>> 
>> More importantly for the container use case, if I want to take a 
>> completely empty jail and do pkg ins nginx (for example), what does 
>> the maintainer of the nginx port need to do to express the minimum set 
>> of the base system that needs to be installed to allow nginx to work?
>> 
>> One of the goals for the pkg base concept was to allow this kind of 
>> use case, easily creating a minimal environment required to run a 
>> single service. With a monolithic base package set, you're going to 
>> need some mechanism other than packages to express the specific base 
>> subset package that you need and I think that you need to justify why 
>> this mechanism is better than using small individual packages.
> 
> Will it not be maintainer's nightmare to take care of all the
> dependencies on the base packages for each port we have in the ports
> tree?

Speaking as a ports maintainer, it will be very annoying. Splitting it 
into a handful of large ass packages, same as you are presented with 
during install, would be best.