harder and harder to avoid pkg
julian at freebsd.org
Wed Oct 12 05:08:16 UTC 2016
On 11/10/2016 5:34 PM, Alfred Perlstein wrote:
> Make a slave port with an abbreviated pkg-plist bruh. ;)
yeeess, good idea, but that won't satisfy the dependency requirements
of other packages... you need to fool other packages, and that's the
hard part. The way to do this is I think for pkg to have the ability
to have two manifests.
We are doing similar to what Roger says, but it's just so much work...
> On 10/11/16 11:59 AM, 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
>> A simple example: libxml2
>> This package installs include files and libraries and dicumentation
>> yet if I build an appliance , I want it to only install a singe file.
>> 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..
>> freebsd-ports at freebsd.org mailing list
>> To unsubscribe, send any mail to
>> "freebsd-ports-unsubscribe at freebsd.org"
More information about the freebsd-ports