What is the actual syntax used to FLAVOR ports?

[Chris]

On Tue, 11 Feb 2020 09:45:53 +0100 Mathieu Arnold mat at FreeBSD.org said

> 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.
> 
Thank you *very* much for the link and reply, Mathieu!
I must admit to being fairly embarrassed for having missed it.

> 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.
Good tip! I think it's simply *easiest* to think of it in terms of languages,
akin to DEFAULT_VERSIONS.
> 
> > 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.)
Given some of the replies to this topic. It might be wise for someone(tm)
to write an introductory to FLAVORS in the Handbook, with perhaps a link to
the FLAVORS section of the porters-handbook.

Thanks again!

--Chris
> 
> -- 
> Mathieu Arnold