harder and harder to avoid pkg

[Matthew Seaman]

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:

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20161012/bdc4065e/attachment.sig>