Why does mail/dovecot use CLucene's Snowball stemmer instead of textproc/snowballstemmer?

[r00ty]

Hi folks,

I'm setting up Dovecot full-text search on FreeBSD (ports mail/dovecot, currently 2.3.21.1). I want to use the FlatCurve (Xapian) FTS backend, and FlatCurve requires the core Dovecot FTS snowball stemming filter.

While looking at the FreeBSD port, I noticed that the snowball stemmer is wired to CLucene's bundled libstemmer, not the textproc/snowballstemmer Snowball library
My questions:

1. Is relying on CLucene's bundled Snowball stemmer a deliberate FreeBSD policy choice? If so, what was the motivation (ABI stability, historical packaging, etc.)?
2. Is there a reason we don't prefer the Snowball library from textproc/snowballstemmer instead? (That port appears maintained/up-to-date.)

I'm not trying to use the Lucene backend itself - I just want the snowball stemming filter for FlatCurve. Any background or guidance on the port's direction here would be much appreciated.

Thanks!

 

[SirDice]

a deliberate FreeBSD policy choice?

It's at the port maintainer's discretion.

If so, what was the motivation (ABI stability, historical packaging, etc.)?

Ask the maintainer.

Is there a reason we don't prefer the Snowball library from textproc/snowballstemmer instead? (That port appears maintained/up-to-date.)

Looks like the port has several different FTS options already, you could ask the maintainer to include the Snowball FTS.

====> Full text search plugins
     ICU=off: Use libicu for FTS unicode normalization
     LUCENE=off: CLucene FTS support
     SOLR=off: Solr FTS support
     TEXTCAT=off: Libexttextcat FTS support

 

[r00ty]

Thanks, SirDice! I thought the maintainers were active on the forum. I'll try reaching out to Larry directly.