harder and harder to avoid pkg

[Kubilay Kocak]

On 12/10/2016 5:55 PM, Matthew Seaman wrote:
> 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 are 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.
>> 
>> 
>> A simple example:   libxml2
>> 
>> This package installs include files and libraries and dicumentation
>> etc.
>> 
>> yet if I build an appliance , I want it to only install a singe
>> file.
>> 
>> /usr/local/lib/libxml2.so.2
>> 
>> 
>> The presence of this file will satisfy any runtime dependencies of 
>> packages that require it.
>> 
>> Unfortunately there is no way to install just this file, and still 
>> report that we have the package loaded, so
>> 
>> pkg will always try to reinstall it leading to a huge mess.
>> 
>> 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.
>> 
>> 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.
>> 
>> Is any of this possible at the moment?
>> 
>> suggestions from the ports/pkg community are appreciated..
>> 
>> 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:

Yep, like this:

Ports framework "variants" proof-of-concept (with poudriere support)
Mar 6 2016 - https://reviews.freebsd.org/D5563

> - 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.

Ports framework "variants" proof-of-concept (with poudriere support)
Mar 6 2016 - https://reviews.freebsd.org/D5563

> 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