Would it be possible to just make hunspell install a non-versioned libhunspell.so symlink, and avoid the bumping problem altogether?

That sounds like a boring solution :) -- but probably yes ^^

This would kinda make more sense if you also added a SPELLING_DEFAULT defined in Mk/bsd.default-versions.mk to set the default spelling engine you want.

So that "USES=spelling" just pulls in the default engine? Or do you mean more generally, that instead of the options in the ports?

In D9025#186565, @mat wrote:

This would kinda make more sense if you also added a SPELLING_DEFAULT defined in Mk/bsd.default-versions.mk to set the default spelling engine you want.

I don't believe this is a select-your-preferred-engine USES; rather it's a "list the LIB_DEPENDS in one place" USES.

Although I love the USES paradigm, I don't think this USES actually makes anything easier. It still requires the same number of lines in the same ports, and if hunspell learns to install libhunspell.so then there'd be no difference between that and this USES.

Give a libhunspell.so symlink a try, Tobias. If it works then I think you should go with that instead. If it doesn't work then I'll come back to this USES.

In D9025#186577, @tcberner wrote:

So that "USES=spelling" just pulls in the default engine? Or do you mean more generally, that instead of the options in the ports?

Yes, it is what the USES paradigm is all about.

In D9025#186578, @adamw wrote:

In D9025#186565, @mat wrote:

This would kinda make more sense if you also added a SPELLING_DEFAULT defined in Mk/bsd.default-versions.mk to set the default spelling engine you want.

I don't believe this is a select-your-preferred-engine USES; rather it's a "list the LIB_DEPENDS in one place" USES.

Then I don't really see the point.

Although I love the USES paradigm, I don't think this USES actually makes anything easier. It still requires the same number of lines in the same ports

The problem it is trying to solve is a QA thing, and this is not the right solution.

Almost nobody ever tests before committing their stuff to the quarterly branch, and it shows, you can't fix a lack of QA by hiding the shit some place else :-)

@jbeich seems to have prepared the symlinking to libhunspell.so in D8887 : Adjust CMake patches for libhunspell.so symlink but don't actually add it yet

So, what should I do with this thing here -- any interest in it theoretically if I add the default-stuff? Or should I let it die? :D

Reviving the discussion on this one (hoping to reduce my list of open reviews). There are two viewpoints here:

• having a centralised place to list spelling-dependencies is possibly useful, but the complexity in ports remains pretty much the same; D8887. as tcberner points out, solves the problem that prompted this in the first place.
• a more generic "USES=spelling" with a default-selection doesn't seem useful, because the configuration options vary for each port. Consider leechcraft. It doesn't depend on spelling in general, it depends specifically on hunspell, and that only if option ROSENTHAL is enabled. So you *can't* change that to "USES=spelling", because it needs a specific spelling-engine. (Er .. I'm assuming that you can't just drop-in-replace hunspell with aspell or vice-versa) Consider otrs. It supports aspell or ispell, not hunspell. So any use of "USES=spelling" would be non-generic except for those rare cases that the upstream can handle any of the spelling engines, finds any one of them automatically, and doesn't need special configure options to turn them on or off.

I don't think the generic solution makes sense, and with D8887 which -- if it actually goes through and the unversioned symlink is installed -- touches all the hunspell depends already, I don't think the less-generic solution adds much.

Vote to discard.