harder and harder to avoid pkg

[Alfred Perlstein]

Make a slave port with an abbreviated pkg-plist bruh.  ;)

-Alfred


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