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.



Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to