# Port flavors - What problem does that fix?



## PacketMan (Dec 1, 2017)

Firstly I should ask, is there a great resource somewhere I should read about flavors, and why this has come to be so I can be more informed?  From this handbook https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/flavors.html I read:

"_Flavors are a way to have multiple variations of a port. The port is built multiple times, with variations. For example, a port can have a normal version with many features and quite a few dependencies, and a light “lite” version with only basic features and minimal dependencies._"

Isn't this the whole concept behind ports and packages? You want some options added or removed you do your `make config` and then off to the races you go?  What problem does this fix?


----------



## rigoletto@ (Dec 1, 2017)

The objective of the ports FLAVORS is to end with the necessity of SLAVE ports. It will affect not just Python stuff but at some point everything what is/have a SLAVE port.

So, things like net-p2p/transmission that have many SLAVE ports (Web, Qt4, Qt5, GTK etc.) will just need one port to build they all in separated packages.

The Python stuff is particularly annoying because it often need several (SLAVE) ports of the same thing just to have (when necessary) py27-,  py34-, py36-, etc.


----------



## PacketMan (Dec 1, 2017)

What do you mean by SLAVE ports?  You mean "runtime dependencies"?  Isn't that the normal FreeBSD design model? Its like Lego's; blocks build onto of blocks. If a port requires other ports to 'get the job done' then that is what is done.

Sorry, I'm not seeing what the real difference is.


----------



## rigoletto@ (Dec 1, 2017)

Using a more complicated setup than Python stuff.

This is the net-p2p/transmission port: HERE.
This is the net-p2p/transmission-cli (the transmission-*) MASTER port: HERE
This is the net-p2p/transmission-qt5 SLAVE port: HERE

All of those ports (and a few more, to cover every variation) are/were necessary to create all the transmission packages flavors, one port for each flavor. Several separated ports what also need to be separated committed, maintained etc.

In a more practical example, let say you saw the cat/xyz port needs update and you want to update it. This is a random Python software which was based on py27-, but  now it is a py36-.

While updating you discover a bunch of its dependencies (all Python stuff) does not still have a SLAVE py36- port in the tree, and you then will also need to create a bunch of SLAVE ports just to update that specific port.

After creating all those SLAVE ports they still have to be reviewed, accepted, committed, and later separated maintained (usually by whom maintain the MASTER port) etc.

EDIT:

With FLAVORs one just need to updated what is in need to be updated, and if all dependencies are already in the tree just test them. Eventually some may still need some minor work but it quite more simple than creating many SLAVE ports.


----------



## jrm@ (Dec 1, 2017)

Official packages are built with default port options.  Users may prefer packages with different options for different scenarios (like the examples lebarondemerde described or, e.g., -nox11 or -lite).  Flavors mean one port can result in many packages, so users will not have to build their own packages as often, since the official packages will be more flexible.


----------



## PacketMan (Dec 1, 2017)

jrm@ said:


> Official packages are built with default port options.  Users may prefer packages with different options for different scenarios (like the examples lebarondemerde described or, e.g., -nox11 or -lite).



Right, and if users require different options they use something like ports-mgmt/poudriere or ports-mgmt/synth to create the packages with the options they require?  Other ports that are a dependency (above or below) will get rebuilt, and life goes on.



jrm@ said:


> Flavors mean one port can result in many packages, so users will not have to build their own packages as often, since the official packages will be more flexible.



So this is more of a convenience thing than a functional design change?


----------



## MarcoB (Dec 1, 2017)

Flavors seem more important for packages than for ports.


----------



## rigoletto@ (Dec 1, 2017)

Actually I think it should not change anything for packages users.


----------



## ANOKNUSA (Dec 3, 2017)

PacketMan said:


> So this is more of a convenience thing than a functional design change?



It fundamentally changes the way ports are built in order to add a convenience that previously didn't exist. It allows a single port to result in multiple packages, letting folks choose different option combinations without having to build the port themselves. I haven't looked into it much at this point, but it potentially allows for multiple versions of the same port to be installed side-by-side as well, similar to "slots" in Gentoo.


----------



## ShelLuser (Dec 3, 2017)

I think this best demonstrates the impact of flavors:


```
$ pkg info -ox setup
py27-setuptools-36.5.0         devel/py-setuptools
py36-setuptools-36.5.0         devel/py-setuptools
```
devel/mason requires the py36 setuptools whereas most other ports use py27, which is also specified in /etc/make.conf, according to /usr/ports/Mk/bsd.default-versions.mk.

In the previous setup this resulted in 2 different ports being installed. But with the new approach one port can fulfill both requirements. At least that's what I make of this.


----------



## Deleted member 30996 (Dec 4, 2017)

What's the status of ports-mgmt/portmaster dealing with this? IIRC I thought I read lebarondemerde state last week it and ports-mgmt/synth were broken, ports-mgmt/poudriere being the only one of the three that wasn't.

freshmeat.org shows the last ports-mgmt/portmaster update being 03 Feb 2017. The last few ports I built with it didn't use Python and compiled without problems.

I have a HDD arriving in the mail tomorrow and had planned to upgrade one of my Thinkpads. It's not a have-to thing though, and was just wondering if that wouldn't be better put off a while. I'd just as soon wait if I couldn't use ports-mgmt/portmaster.


----------



## rigoletto@ (Dec 4, 2017)

ports-mgmt/synth is working already.


----------



## PacketMan (Dec 4, 2017)

lebarondemerde said:


> ports-mgmt/synth is working already.



Mostly.  Looks like John is still working on some minor issues.  

I'm gonna wait a few weeks to let everything shake out, before I do my next round of updates on my 'production' machines.  I got a couple 'lab' servers I will play around with if/when I get some time.


----------



## phoenix (Dec 4, 2017)

Trihexagonal said:


> What's the status of ports-mgmt/portmaster dealing with this?



Portmaster is unmaintained.  If no one steps up to maintain it and add support for FLAVOR (and any future features like multi-package support), then it will become abondonware and useless.

Granted, once multi-package support hits, and FLAVORs expand to the rest of the tree, the use-case for compiling ports locally will be pretty much nil.  A strictly binary package-using system will be doable as most of the need to compile from source (selecting specific OPTIONS) will be nullified.  (For the most part, there will still be the odd port with NO_PACKAGE set, and mutually-exclusive OPTIONS that will require building from source, but it should be the exception and not the norm.)

At least, that's the hope and the dream.


----------



## PacketMan (Dec 4, 2017)

phoenix said:


> Granted, once multi-package support hits, and FLAVORs expand to the rest of the tree, the use-case for compiling ports locally will be pretty much nil.  A strictly binary package-using system will be doable as most of the need to compile from source (selecting specific OPTIONS) will be nullified.



I struggle to see how that could be likely. A lot of ports have a lot of options, and from what I see in this forum there are a lot of users customizing these port options for their needs.  I really can't imagine there be a flavour of port representing every possible combination of options on a per port basis.

I'm still not getting this FLAVORS thing.  Wish there were some URLs I could go to with official detailed explanations.  I think I'll just have to wait and see, and hopefully will have a ah-ha moment soon enough.


----------



## rigoletto@ (Dec 4, 2017)

FLAVORs are easy to understand.

Think a random python port that can be built against python:2 and python:3 (two flavors), probably most of the python stuff.

To build two packages, py27 and py36 versions, you need to have two separated ports. One to build the python:2 version and another one (usually a SLAVE port) to build the py36 package.

With the new FLAVOR thing you just need one port to build both (or more if necessary: py34, py35 etc.).

EDIT: a SLAVE port basically is a port that have what are different of the MASTER one.

This is the editors/vim-lite (SLAVE) port:

```
PKGNAMESUFFIX=   -lite

COMMENT=   Improved version of the vi editor (lite package)

CONFLICTS_INSTALL=   vim-[0-9]*

LITE=       yes
MASTERDIR=   ${.CURDIR}/../vim

.include "${MASTERDIR}/Makefile"
```


----------



## PacketMan (Dec 4, 2017)

lebarondemerde said:


> To build two packages, py27 and py36 versions, you need to have two separated ports. One to build the python:2 version and another one (usually a SLAVE port) to build the py36 package.  ......  With the new FLAVOR thing you just need one port to build both (or more if necessary: py34, py35 etc.).



Yeah yeah I get the new structure, but I do not get what problem is being fixed.  The old way worked fine for years and I don't recall reading a 'theme' amongst users that the current up-to-now structure desperately needed an overall.  So what if the old way you needed two separate ports to build two versions of something. Truth be told I prefer the 1:1 requirement.  This seems more cosmetic, more convenience based of a change than anything substantial.  I'm not saying I'm against this, I'm just trying to see what the substantial requirement/justification is for this. Feels more like a nice-to-have than a 'required-to-support-upcoming-changes-in-release-xxyy'.


----------



## rigoletto@ (Dec 4, 2017)

For starters it make the life of people maintaining ports more "soft", and allow more time to work on more things.

EDIT: in other words, FLAVORs do simplify most of the logistics of maintaining ports.


----------



## PacketMan (Dec 4, 2017)

Ah-ha!  Well if it makes life easier for all the coders out there, and doesn't make it harder for the ends users, I'm in.  

Time will tell.


----------



## Deleted member 30996 (Dec 5, 2017)

phoenix said:


> Portmaster is unmaintained.  If no one steps up to maintain it and add support for FLAVOR (and any future features like multi-package support), then it will become abondonware and useless.



As will my tutorial since it specifically uses ports-mgmt/portmaster. Not to mention I prefer using ports above pkg.



> Granted, once multi-package support hits, and FLAVORs expand to the rest of the tree, the use-case for compiling ports locally will be pretty much nil.



So `# make install clean` will still work?

I do use pkg on my OpenBSD box, which doesn't even have portmaster in its repository, so I do know the advantages of doing so.


----------



## phoenix (Dec 5, 2017)

`# make install clean` will always work.  It has to in order for the ports tree to function at all.  

There are a couple of different efforts underway to get FLAVOR support added to portmaster, so it looks like it may become maintained again, and brought up-to-speed with all the changes to the ports framework.


----------



## Deleted member 30996 (Dec 5, 2017)

phoenix said:


> `# make install clean` will always work.  It has to in order for the ports tree to function at all.



Well, I have built it that way before... 

I'm happy to hear ports-mgmt/portmaster might get a maintainer and will wait to see how things work out.


----------



## uzsolt (Dec 10, 2017)

PacketMan I think the FLAVORS is a good extension (to replace slave ports). In some linux distros exists "subpackages" - IMHO the FLAVORS is similar with it.
For example on servers doesn't need the full Xorg infrastructure and GUI of different programs. The deskutils/fet is a timetable generator which uses Qt but can build it without a GUI. With FLAVORS easily create fet-cli and fet-gui packages - desktop users will install fet-gui, server users will install fet-cli. With using of ports (to build only the CLI version because of decrease dependencies) would waste more resources (disk space, cpu power) than installing of fet-gui (with Qt-dependencies).


----------



## MarcoB (Dec 10, 2017)

But with ports this is already possible, using buildoptions. So what's the advantage of flavors in ports?


----------



## uzsolt (Dec 10, 2017)

Once again: you don't need ports tree and waste resources to build with non-default options - can install a _package_ from repository (takes some seconds instead of some ten minutes or more).
Yes - it's nearly impossible to create every packages with every combination of options but can useful to create some packages with major combinations of options (e.g. -full or -lite versions).


----------



## MarcoB (Dec 10, 2017)

Well I like to build from ports and tweaking them with just the right options set.
Are the buildoptions being removed from ports, or are flavors added to the ports as an extra layer?


----------



## tobik@ (Dec 10, 2017)

MarcoB said:


> Are the buildoptions being removed from ports


No, of course not! Flavors are just an extra layer.


----------



## MarcoB (Dec 10, 2017)

Ok thanks. Looks like not much is changing for the portsuser I guess.


----------



## rigoletto@ (Dec 10, 2017)

At the ports side those changes affect primary the maintainers, specially those who maintain python stuff. FLAVORS make the things a lot simpler.


----------



## MarcoB (Dec 10, 2017)

I maintain a few ports but I don't think they are affected.


----------



## PacketMan (Dec 10, 2017)

My suspicion is FLAVORs will mean little to 90% of the FreeBSD users. Most will modify the combination of port options because of our needs, and there will not be a prebuilt flavoured packaged for that. So Portmaster, Synth, and Poudrier users will continue doing what they normally do.  If it helps the developers/maintainers then great, all the power to them.


----------

