Date: Tue, 11 Oct 2016 16:20:43 -0700 From: Julian Elischer <julian@freebsd.org> To: olli hauer <ohauer@gmx.de>, "ports@FreeBSD.org" <ports@freebsd.org> Cc: Baptiste Daroussin <bapt@FreeBSD.org> Subject: Re: harder and harder to avoid pkg Message-ID: <3d95a001-b6e1-eaed-0feb-6838396fce36@freebsd.org> In-Reply-To: <e1bb369e-9ffa-0ba4-acfd-f8dd626d54db@gmx.de> References: <638fe078-80db-2492-90be-f1280eb8d445@freebsd.org> <e1bb369e-9ffa-0ba4-acfd-f8dd626d54db@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3d95a001-b6e1-eaed-0feb-6838396fce36>