What is the actual syntax used to FLAVOR ports?

[Mathieu Arnold]

On Mon, Feb 10, 2020 at 09:02:34PM -0500, Ernie Luzar wrote:
> Kevin Oberman wrote:
> > On Sat, Feb 8, 2020 at 1:27 PM Chris <portmaster at bsdforge.com> wrote:
> > 
> > > OK I know FLAVOR is an evolving concept. But I can not find
> > > the FLAVOR documentation. Only references in the porters
> > > handbook. What I think needs to be available is an entire
> > > list of flavor tags for all (port) categories.
> > > For example;
> > > make FLAVOR=python27 returns the error use py27.
> > > OK now I know how to flavor, and build python flavors.
> > > But what of Perl?
> > > make FLAVOR=perl2.8. Nope. How about make FLAVOR=p5-28,
> > > and so it goes...
> > > Does there exist a definitive list of flavors? It'd
> > > also be valuable for defining defaults in make.conf(5)
> > > 
> > > Thanks!
> > > 
> > > --Chris
> > 
> > 
> > The problem is not having a clear understanding of what a FLAVOR is and
> > when it is used.
> > 
> > FLAVORS are generally a way to deal with the problem of incompatible
> > versions and Python is the poster child. Python2 and Python3 are two
> > version of a VERY popular language that have significant syntax
> > incompatibilities. While a program written for gcc-4.2 should work fine
> > when compiled with gcc-7, it is VERY unlikely that a program written for
> > Python2 will work with Python3. While the changes needed are often fairly
> > straight forward, they have to be made. The result is a requirement of
> > having both interpreters installed and two packages of of most Python
> > libraries built from a single source.
> > 
> > Adding FLAVORS for a port is an expensive operation and is never lightly
> > approved by the ports management team as it adds a great deal of complexity
> > and both human and machine overhead. Requests to FLAVOR a port are
> > carefully reviewed and will only be approved with adequate justification.
> > 
> > In the case of Perl, no attempt to flavor it has been needed. Most Perl
> > packages (p5-*) will work with any of the three available ports. In most
> > cases they may be installed and continue to work across versions with no
> > changes. Python (py-) ports MUST be reinstalled to move from Python2 to
> > Python3. Some have not had required changes to work with Python3 made and,
> > initially, almost none did. Some have now been written with no support for
> > Python2. All of this has to be properly handled by the package building
> > system and it is not at all trivial.
> > 
> > As of today, I believe the only FLAVORed ports are those using emacs,
> > lazarus, php, and, of course, python. By "using", I mean that the port
> > Makefile includes "USE_PYTHON" or similar USE_ definitions of the other
> > languages. (Yes, emacs is not a language, but elisp, the core of emacs, is
> > and lazarus is an IDE for Pascal.)
> > 
> > I'm sorry of this is not entirely clear, but I hope it helps and I hope it
> > is all correct. I may have worded some of it poorly.
> > --
> > Kevin Oberman, Part time kid herder and retired Network Engineer
> > E-mail: rkoberman at gmail.com
> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> 
> wow the above reply is not how I remember how things were envisioned when
> this flavor function was first talked about. Having to get permission first
> and being limited to languages was never talked about and not at all a
> requirement.

Having to get permissions was never envisioned, and we will stop having
it as a requirement when people stop trying to forcefully do very silly
things, it will probably be relaxed when we have subpackages.
It is not at all limited to languages, I have no idea where that came
from.  You only have to grep for '^FLAVORS=' to see that.

> It was envisioned as a way to per can a set of different
> defaults so a package with pre canned defaults would be auto built in the
> ports system that is different from the basic defaults.  ON the subject of
> documentation about how to set up flavors for a port is totally lacking at
> this point. You know the old saying, developers are good programmers but are
> terrible at documenting their work if they do it at all. So with that in
> mind do your own thing following what you see for flavored languages as a
> loosely followed guide.

Flavors have been documented from day one.

https://www.freebsd.org/doc/en/books/porters-handbook/flavors.html

(I kinda know because I wrote (most of) the flavors code, and I also
write (most of) the documentation.)

-- 
Mathieu Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20200211/322245a4/attachment.sig>