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

 

[Erichans]

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

ad #2: I'm not sure what you mean by that.

ad #1
Maybe, maybe not. pkg-search(8):

SYNOPSIS
       pkg    search	[-U]	[-r   reponame]	  [-S	search]	  [-L	label]
	   [-Q query-modifier] [-Cegix]	pattern
       pkg search [-cDdfopqRsU]	[-r reponame] [-Cegix] pattern
   [...]
DESCRIPTION
       pkg  search is used for searching package repository catalogues.	 Pack-
       ages available for installation can be matched by  name,	 by  name  and
       version,	 by  origin, or	by text	in the package comments	or package de-
       scriptions.

It describes what pattern is in the context of pkg-search(8).
However, I'd prefer that the user is helped by an additional "link" connecting pattern to its meaning.
Something like:

SYNOPSIS
       pkg    search	[-U]	[-r   reponame]	  [-S	search]	  [-L	label]
	   [-Q query-modifier] [-Cegix]	pattern
       pkg search [-cDdfopqRsU]	[-r reponame] [-Cegix] pattern
   [...]
DESCRIPTION
       pkg  search uses pattern to search the package repository catalogues.	 Pack-
       ages available for installation can be matched by  name,	 by  name  and
       version,	 by  origin, or	by text	in the package comments	or package de-
       scriptions.

To shorten the "horribly large" list, use for example an extended regular expression as a pattern, pkg-rquery(8):

[1-0] # pkg rquery -x '%n' '^vim.*'
vim
vim-colorschemes-legacy
vim-gtk2
vim-gtk3
vim-lsp
vim-motif
vim-tiny
vim-x11
vimb
vimpager
vimpager-gtk2
vimpager-gtk3
vimpager-motif
vimpager-neovim
vimpager-tiny
vimpager-x11
vimpc
[2-0] #

Often, the flavor is added as a suffix (as is the case with vim) in the package name as follows (<package-name-sec> is AFAIK the port name):
<package-name-sec>-<package-flavor>
However, it can also be a prefix, appear somewhere in the middle, or not have an explicitly defined flavor name as part of the package name at all.*

There seems to be no explicit first class field or "flavor" property encoded for a (flavored) package, that is:

[1-0] % grep -E '^FLAVORS' /usr/ports/editors/vim/Makefile
FLAVORS=        console gtk2 gtk3 motif x11 tiny
[2-0] %

cannot be obtained by a querying for a "flavor" property. It is however part of the annotation of a package:

[81-0] # pkg rquery -x '%n %At: %Av' '^vim.*' | grep flavor: | column -t
vim              flavor:  console
vim-gtk2         flavor:  gtk2
vim-gtk3         flavor:  gtk3
vim-motif        flavor:  motif
vim-tiny         flavor:  tiny
vim-x11          flavor:  x11
vimpager         flavor:  console
vimpager-gtk2    flavor:  gtk2
vimpager-gtk3    flavor:  gtk3
vimpager-motif   flavor:  motif
vimpager-neovim  flavor:  neovim
vimpager-tiny    flavor:  tiny
vimpager-x11     flavor:  x11

___
* Various formats (other than using the flavor name as a suffix) for embedding of the flavor in a package name (a selection is made by means of the grep filter):

# pkg rquery -x '%n %At: %Av %R' '.*' | awk '$2 == "flavor:" { if ( !match( $1, $3"$") ) print }' | grep -E 'gcc12|wifi-firmware-(mt76-)?kmod' | nl -ba | column -t        1   aarch64-gcc12            flavor:  aarch64    FreeBSD
2   amd64-gcc12              flavor:  amd64      FreeBSD
3   armv6-gcc12              flavor:  armv6      FreeBSD
4   armv7-gcc12              flavor:  armv7      FreeBSD
5   i386-gcc12               flavor:  i386       FreeBSD
6   powerpc-gcc12            flavor:  powerpc    FreeBSD
7   powerpc64-gcc12          flavor:  powerpc64  FreeBSD
8   riscv64-gcc12            flavor:  riscv64    FreeBSD
9   wifi-firmware-kmod       flavor:  default    FreeBSD
10  wifi-firmware-mt76-kmod  flavor:  mt76       FreeBSD
11  wifi-firmware-mt76-kmod  flavor:  mt76       FreeBSD-kmods

#1-7: prefix
#9: no explicit flavor name addded
#10-11: flavor appears somewhere in the middle of the package name.