Flavors documentation?

[olli@]

Where exactly is the “flavors” feature documented? I mean, for a user, not for a ports developer. We now have that feature for almost 10 years, but the documentation is still very good at hiding it from users …

The respective chapter in the FreeBSD Handbook says nothing about ports flavors. The ports(7) manual page mentions it in a terse example (it’s example 3 near the bottom of the page), but it doesn’t really explain anything.

What is the “official” way to find out if a port has flavors? And how to get a list of the supported flavors, and which one is the default flavor?

Of course I can look at the Makefile (I’m a developer, so I know how to read Makefiles), I can type make -V FLAVORS, and by inspecting the Ports framework's *.mk files you can find out that there is such a thing as make pretty-flavors-package-names – all of that is not documented anywhere. Or did I miss something?

On a related note: Some ports have migrated from options to flavors for X11 support (for example net/mtr). I can see that this makes things easier for package building. But it makes things more difficult for users. If X11 is an option, when building the port, the usual config dialog pops up, so the user clearly sees that he has the option to build the port with or without X11 support. However, now that it is a flavor instead, that fact is pretty much hidden. When he builds the port, the dialog does not mention X11 at all, and the fact that the port may be built without X11 support is not apparent anymore.

TL;DR – In my opinion, the flavors feature is a good idea basically, but the implementation leaves something to be desired, as does the documentation.

 

[Phishfry]

Here is a slightly unrelated qualm.
What is the difference between flavors and Master/Slave ports like u-boot.
Put another way why flavors a all?
edk2 uses flavors and u-boot uses master/slave arrangement.

I can see the utility for something like astro/gpsd
Ports released a flavor called gpsd-nox11 which I appreciate but why did a command line utility need x11 anyway? Should have been option=off
But I guess they are following upstream and there is an xgps application that is part of base gpsd.
Still why force a x11spitball at users... That is probably an upstream gripe.

But because gpsd adopted flavors the dependent port of astro/gpxloggerd would drag in x11 anyway because it did not have a nox11 flavor.
So that needed a flavor to work too because upstream dependency on gpsd.
Very imperfect world.

 

[T-Aoki]

Here is a slightly unrelated qualm.
What is the difference between flavors and Master/Slave ports like u-boot.
Put another way why flavors a all?
edk2 uses flavors and u-boot uses master/slave arrangement.

I can see the utility for something like astro/gpsd
Ports released a flavor called gpsd-nox11 which I appreciate but why did a command line utility need x11 anyway? Should have been option=off
But I guess they are following upstream and there is an xgps application that is part of base gpsd.
Still why force a x11spitball at users... That is probably an upstream gripe.

But because gpsd adopted flavors the dependent port of astro/gpxloggerd would drag in x11 anyway because it did not have a nox11 flavor.
So that needed a flavor to work too because upstream dependency on gpsd.
Very imperfect world.

My understanding in the advantage of FLAVOR over parent (master) / child (slave) ports is making *_DEPENDS descriptions easier.

For example, sysutils/password-store depends on devel/git, while sysutils/try-rs depends on devel/git@tiny (tiny FLAVOR of devel/git).
This way, if any FLAVOR is OK, simply specifying category/portname format is sufficient, while specific FLAVOR can be speficied like category/portname@flavor format if wanted.

But anyway, clean room builders like ports-mgmt/poudriere always preferres (unless specifically to do so) default FLAVOR, as nothing is pre-installed unlike bare-metal builds.

Note that "parent/child" is NOT an official/historical naming, but quite unfortunately, there are a number of persons who are quite offencive to "master/slave" namings outside here, even though it's just long-standing and purely technical terms. Life became too hard recently for engineers.

 

[JohnK]

Note: Vim has flavors so I'm using that as an example.

Most people are going to be using packages (not ports) so, if we search for a package we want (Vim).

```
pkg search vim
```
Gives a bunch of results:
vim-9 ...
vim-gtk ...
vim-motif ...
vim-tiny ...
vim-x11 ...

Then if you do a more refined search:
```
pkg search -Q full vim-9
```
At the bottom there is a list of "FreeBSD Vim *packages*" with a brief description of each flavor.

Therefore (thinking out-loud with no real substance).
1. `pkg(8)` needs to be fixed. -e.g. `pkg search` should not return "p5-shell-envimporter-1..." because someone searched for "vim". This list is horribly large sometimes.
2. The use of the 'full' query modifier for 'search' needs to be consistent (but with zero actual enforcement ability).