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.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
