On 12/10/2016 1:13 AM, Vlad K. wrote:
On 2016-10-11 20:59, Julian Elischer wrote:
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.
Is as adding a "HEADERS" or whatever you want to call the option to
ports, a solution? Like we have DOC for documentation, an option
that could be PLIST sub'd and switch installation of
include/whatever.h and friends?
what I really need is a RUNTIME option that produces a package with
only those files needed to satisfy external run-time depdencies, or
the actual demands of the user itself. However since those files are
all in the regular package, It'd make sense to just apply the regular
package to some filter that only allowed those files to be extracted.
For many packages the whole output would be a single file. (This would
be true for any package that produces a single .so such as libjpeg or
libtiff etc. ). The pkg database would however report the package
being installed, thus satisfying other packages that look in the
database for dependencies. Giving it another name (e.g.
foo-runtime-3.2 ) would make the dependencies not match it.
Yes it's a ton of work requiring to go through many ports, but
looking at a random sample, it could be scripted and manual labor
reduced.
To me something like this sounds very much consistent what other
options, like DOC and MANPAGES, already do. And with individual
options you don't presume package roles like -dev or -runtime or
-whatever and you can combine as you want them.
And eventually if, hopefully when, package variants are implemented,
maybe the official pkg repo can include all the variants, but then,
I think, that's only a matter of logistics and resource available to
build all those combinations and store them. But the basic mechanism
for it should be a port option, imho.
_______________________________________________
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"
