Am 12.03.2019 um 10:27 schrieb Mateusz Piotrowski:
Author: 0mp (ports committer)
Date: Tue Mar 12 09:27:37 2019
New Revision: 345057
URL: https://svnweb.freebsd.org/changeset/base/345057
Log:
ports.7: Add an example of how to use flavors
At the moment the manual page is not documenting how to build
a flavored package. Let's start documenting flavors with
an example of a typical use case.
Reported by: cem, dim
Reviewed by: bcr, cem, mat, matthew
Approved by: cem (src)
Differential Revision: https://reviews.freebsd.org/D19531
Modified:
head/share/man/man7/ports.7
Modified: head/share/man/man7/ports.7
==============================================================================
--- head/share/man/man7/ports.7 Tue Mar 12 09:24:58 2019 (r345056)
+++ head/share/man/man7/ports.7 Tue Mar 12 09:27:37 2019 (r345057)
@@ -25,7 +25,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd February 12, 2019
+.Dd March 12, 2019
.Dt PORTS 7
.Os
.Sh NAME
@@ -587,7 +587,7 @@ The following command builds and installs Emacs.
.Ed
.It Sy Example 2\&: No Installing Dependencies with Xr pkg 8
.Pp
-The following examples shows how to build and install a port without having to
+The following example shows how to build and install a port without having to
build its dependencies.
Instead, the dependencies are downloaded via
.Xr pkg 8 .
@@ -603,6 +603,16 @@ The drawback is that
.Xr pkg 8
offers only packages built with the default set of
.Va OPTIONS .
+.It Sy Example 3\&: No Building a Non-Default Flavor of a Port
+.Pp
+The following command builds a non-default flavor of a port.
+(In this case
+.Pa devel/py-pip
+is going to be built with Python 3.7 support.)
+.Bd -literal -offset 2n
+.Li # Ic cd /usr/ports/devel/py-pip
+.Li # Ic env FLAVOR=py37 make build
Since cem and dim seem to stumbled over the missing FLAVOR
documentation, I see my main objection against current FLAVOR
implementation confirmed: Build stage must'nt silently chose a default
FALVOR, but an OPTIONS-like dialog must inform the user and she _must_
choose one.
FLAVOR is a severe regression for ports usage to all FreeBSD users imho.
Users can't see if a port makes use of FLAVOR or not.
User won't get informed that default FLAVOR is in use.
Users can't see what FLAVORs are supported (and/or why, with what
consequences...).
Port/Package name relation gets lost (also for make(1) variables widley
used in my scripts, which I still have to track down...).
FLAVOR silently broke $WRKDIRPREFIX.
If of any use, it's solely for maintainers, but at the cost of users.
The ports options framework is not really user friendly too, but does a
basic job in guiding users. FLAVOR does the opposite.
There was nothing wrong with slave ports. If maintainers have to spend
a fraction more time on slave ports than on FLAVORized ports, it's worth
every second, instead of distracting users. The more poudriere
optimization the ports tree gets, the more distraction for
users/admins/engineers/students comes along and FreeBSD loses one
elementary strength of the project, imho.
Instructing users to set an environment variable to a value, which they
have to lookup from a Makefile, is a very poor usability design, imho.
Hope this isn't the completely wrong place to point to ports stuff...
Thanks,
-harry
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
