What is the actual syntax used to FLAVOR ports?

Ernie Luzar luzar722 at gmail.com
Tue Feb 11 02:02:37 UTC 2020


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. 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.


More information about the freebsd-ports mailing list