harder and harder to avoid pkg

[olli hauer]

On 2016-10-11 20: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
> 

Hm, do you build your own packages or using pre build packages?

just for interest and testing the following hack will do what you want, but results in duplicate category and some other minor errors (needs some better hacking ...)

$ cat libxml2/Makefile.local
post-stage:
	@${RM} -rf ${STAGEDIR}${PREFIX}/include/libxml2
	@${ECHO} 'lib/libxml2.so.2' > ${TMPPLIST}


A better method would be to use a tool like portsharker together with ports-mgmt/poudriere(-devel)
A really short hint how to use it can be found here:
 https://github.com/freebsd/poudriere/blob/release-3.1/doc/portshaker.wiki

Anyway, until now should be possible with some effort, perhaps it is possible to get for such purpose an additional make target that is running after stage but before the package is created.