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
Description: OpenPGP digital signature