security/spass: Update to 3.2 and create a Qt5 slave port

[kai]

Summary

- Create an additional slaveport to offer CLI-only (master port) and Qt5 (slave port) packages.

Changelog since 3.0:

- Minor tweaks for the CLI version
- Additional Qt5 GUI version

PR: 238621
Submitted by: Thomas Merkel <[e-mail]> (initial patch)
Approved by: ???

Test Plan

• poudriere (11.2-, 11.3-, 12.-RELEASE, 13.0-CURRENT@r349352 amd64 + i386) for both master/slave ports -> OK
• portlint -> OK (gives warning about URL of WWW field that exceeds 80 chars)

[mat]

This looks like this is trying to do subpackages with flavors, which we do not want.

security/spass/Makefile

30

Remove :U... it is set before this line.

[kai]

Addressing @mat's suggestions.

[kai]

In D21084#461799, @mat wrote:

This looks like this is trying to do subpackages with flavors, which we do not want.

Thank you for your info and looking at it.

Hrmkay, in that case if FLAVORS are not the desired approach, there might be two alternatives as far I know. If I'm not mistaken, the subpackage feature is still in WIP via D16457 ? It would be an ideal alternative once it lands.

The second alternative I can think of would be to create a slave port but that's a bit too far off for such a small port like security/spass is, imho.

[mat]

In D21084#462347, @kai wrote:

In D21084#461799, @mat wrote:

This looks like this is trying to do subpackages with flavors, which we do not want.

Thank you for your info and looking at it.

Hrmkay, in that case if FLAVORS are not the desired approach, there might be two alternatives as far I know. If I'm not mistaken, the subpackage feature is still in WIP via D16457 ? It would be an ideal alternative once it lands.

The second alternative I can think of would be to create a slave port but that's a bit too far off for such a small port like security/spass is, imho.

Well, we will not approve flavors that are there to emulate subpackages, so it should really be a slave port. Also, if both ports could be installed at the same time, it would be better.

[kai]

In D21084#463747, @mat wrote:

Hrmkay, in that case if FLAVORS are not the desired approach, there might be two alternatives as far I know. If I'm not mistaken, the subpackage feature is still in WIP via D16457 ? It would be an ideal alternative once it lands.

The second alternative I can think of would be to create a slave port but that's a bit too far off for such a small port like security/spass is, imho.

Well, we will not approve flavors that are there to emulate subpackages, so it should really be a slave port. Also, if both ports could be installed at the same time, it would be better.

Ok, in that case, if a slave port really makes sense I'll update this diff shortly.

[kai]

Switch from using FLAVORS to master/slave ports as suggested by @mat.

[mat]

security/spass-qt5/Makefile

8

Do those two packages have to conflict ?

Cannot this one only ship with bin/spass-qt?

Also, you should not use options, because one could enable QT5 on the master port, and then this one is useless.

12

This is the default value, please remove.

[kai]

Addressing @mat's pointers/questions:

• Remove the QT5 option completely and add nearly all Qt5 related stuff to the slaveport.
• Use a helper variable _WITH_QT5 to determine which version is built to append the CMAKE_ARGS.
• The CLI binary is bundled with the GUI version but each program works independently from each other. Thus remove the CLI version from the GUI-only slaveport and eliminate the CONFLICT_INSTALL entries that are now superfluous.
• Minor fix: Use devel/qt5-buildtools only during the build process. It's not required for runtime.

[mat]

Remove portmgr, no more flavors.

security/spass-qt5/Makefile

7

USES is not set before, no need for +=.

14

You could remove this and use the fact that there is a PKGNAMESUFFIX set for the test in the master port.

[kai]

• Change += from the slave port to =, it's indeed not set before.
• Remove the _WITH_QT5 helper variable from both ports and use a test against PKGNAMESUFFIX instead.