On 14/10/2016 4:27 AM, Matthieu Volat wrote:
On Fri, 14 Oct 2016 13:05:35 +0200
David Demelier <demelier.da...@gmail.com> wrote:
2016-10-14 11:22 GMT+02:00 Baptiste Daroussin <b...@freebsd.org>:
It is imho doable in both sides.
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.
IIRC, rpm builders have script that automate this by finding files in
standard directories. Probably by checking in the stage a include/
directory and "tag" it as the development part.
Unless things changed very recently, not quite : you have to pile subpackage
declaration and files sections according to the subpackages you create. The
only things it has to ease the burden is you can use wildcard patterns to
It will be the most smart way of doing this but still require some
addition to pkg. Probably like:
- pkg install mylib
- pkg install -t dev mylib
- pkg install -t runtime mylib
- pkg install -t dev,runtime,doc mylib
Just thinking ;)
More options, then more options to `pkg info` to get what was installed when something
cannot build, then more pkg search options and manpage because more "-t" flags
will be added and we don't know what's needed?
I'm glad people are at least thinking about it...
I don't think there are so many categories. Are we installing onto a
development machine, user machine, or an appliance? appliances don't
need man pages. User machines need man pages for programs but not for
libraries and developer machines.. everything..
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"