Page MenuHomeFreeBSD

New Mk/Uses/spelling.mk to depend on aspell/hunspell/ispell/[...?]
AbandonedPublic

Authored by tcberner on Jan 2 2017, 4:36 PM.

Details

Reviewers
adridg
rakuco
mat
Group Reviewers
O5: Ports Framework(Owns No Changed Paths)
portmgr
kde
Summary

Recently, when hunspell got updated to 1.5 in head but stayed at 1.3 in quarterly we had issues with the kde-test jenkins of @swills as ports depending on libhunspell had libhunspell-1.5.so:texptroc/hunspell, which obviously did not work on the quarterly branch.

So introduce Mk/Uses/spelling.mk that spews out the LIB_DEPENDS line, this way ports don't have to hardcode the hunspell so-version and it is only in one place.

At the moment this supports the arguments aspell, hunspell and ispell.

  • I skipped editors/xmlcopyeditor, as arc didn't like the non-utf-8 encoding.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 6540
Build 6765: arc lint + arc unit

Event Timeline

tcberner retitled this revision from to New Mk/Uses/spelling.mk to depend on aspell/hunspell/[...?].
tcberner updated this object.
tcberner edited the test plan for this revision. (Show Details)
tcberner added reviewers: kde, rakuco, mat, adridg.
tcberner added a subscriber: swills.
tcberner edited edge metadata.

also handle ispell from textproc/aspell-ispell, and do some argument checking

tcberner edited edge metadata.

Forgot one _SELECTED line.

tcberner retitled this revision from New Mk/Uses/spelling.mk to depend on aspell/hunspell/[...?] to New Mk/Uses/spelling.mk to depend on aspell/hunspell/ispell/[...?].Jan 2 2017, 6:22 PM
tcberner updated this object.
tcberner edited edge metadata.

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.

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.