harder and harder to avoid pkg

[Julian Elischer]

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