On 10/14/16 10:22, Baptiste Daroussin wrote: > We could imagine tagging the plist/manifest so pkg can allow a user to install > only the things tagged as runtime for exemple which would do the job. for what > Julian is asking for beside adding lots of complexity pkg(8) and adding a > nightmare in the solver. > > That would "please" the people that want "hey keep the giant flat package as > it > is better for dev given I don't have to install the -devel version something" > and the people wanting fine grain selection if they need to. > > But on the ports side that would be a nightmare having to tag all the plist > (and > this cannot be automated because there are to many corner cases.
You still need something like this whichever way sub-packages are
implemented -- compiling and staging the port generates a whole load of
files and you somehow have to identify each of them as docs, examples,
whatever either for tagging in the plist or for turning into sub-packages.
Some of that you can do heuristically, but yeah -- this classification
job would be a thing that port maintainers get to enjoy.
It should be possible to create meta-packages that do nothing except
depend on commonly used combinations of sub-packages as a convenience
for people installing software at the command line. For example one
that could have the same overall result as installing an all-in-one
package at the moment. I believe something like this is planned for the
base system packages.
> Having the port that grows the feature would be really nice because no work
> would be needed on pkg :) and that would reduce cluster package building as we
> could merge qt, php etc into one port that builds multiple sub packages.
True, that would save a number of repetitive compilations. Of course,
what you save by implementing sub-packages you'ld immediately lose (and
more) by implementing package flavours.
Cheers,
Matthew
signature.asc
Description: OpenPGP digital signature
