svn commit: r345057 - head/share/man/man7

[Harry Schmalzbauer]

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