New port: finance/dash: Virtual peer-to-peer currency client {PENDING dialog4ports approval}

[yuri]

Summary

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224467

I formatted this port into using flavors. There are 3 flavors:

• daemon: Dash daemon and rc script
• cli: client and utils
• qt: Qt UI

Flavor in this context represents the role of the package in the Dash system.
Users who need to run daemon should install: pkg install dash-daemon
Users who want to access the daemon should install: pkg install dash-cli
Users who want to use GUI should install: pkg install dash-qt

Each flavor installs different file sets.

This port is a candidate for not-yet-implemented sub-packages.
Until then, it looks like flavors can be utilized to achieve a very similar effect.

[mat]

I do not think flavors is the right fit here. Use options, and when they become available, subpackages.

[yuri]

In D13566#283787, @mat wrote:

I do not think flavors is the right fit here. Use options, and when they become available, subpackages.

But why don't you think they are a fit? What is a problem? I've built, installed, ran all 3 of them, it all looked fine.

[mat]

Flavors are for the cases when a port MUST be built multiple times to generate the different variations. For example, you cannot build both py27-foo and py34-foo in one go, you have to build the Python 2.7 version, then build everything again with Python 3.4.

Here, you can build everything at once, so it is not a good fit for flavors.

[yuri]

In D13566#283791, @mat wrote:

Flavors are for the cases when a port MUST be built multiple times to generate the different variations. For example, you cannot build both py27-foo and py34-foo in one go, you have to build the Python 2.7 version, then build everything again with Python 3.4.

Here, you can build everything at once, so it is not a good fit for flavors.

No, port options wouldn't work in this case.

Some options are only for some flavors/parts. If to make a superset of options, then irrelevant options will be available for pieces that don't need them.
This will be a mess.

Currently it is handcrafted, and it is all correct. With options some parts will be incorrect.

This is the nicest way to create ports for Dash I see now. Let's commit it this way, and when sub-packages will be available, convert to sub-packages. Otherwise, what would be the damage if this is committed?

[mat]

In D13566#283967, @yuri wrote:

This is the nicest way to create ports for Dash I see now. Let's commit it this way, and when sub-packages will be available, convert to sub-packages. Otherwise, what would be the damage if this is committed?

No. Do it with options, it will actually be shorter to write than with flavors.