On 11/10/2016 12:51 PM, olli hauer wrote:
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?
yes we build them, for simple ones, but
for java or some of the more complicated ones, we PREFER to use the
precompiled ones.
This is because (as mentioned in the email) the explosion of
dependencies means that compiling our own is getting less and less
feasible.
Especially if we have our own changes in some of the prerequisite modules.
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}
That's true and in fact we have the technology in house to do that,
but it's a very messy solution, and not terribly reproducible,
requiring lots of human intervention in the long run. it also
produces accounting issues as now we need to have two versions of each
pkg (with the same name),
One that we need to install into the build environment (with include
files, etc) and one for installing into the target appliance image.
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.
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
