Bug 198517 - new port databases/riak2
Summary: new port databases/riak2
Status: Closed Not Accepted
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on: 198656
Blocks:
  Show dependency treegraph
 
Reported: 2015-03-11 11:04 UTC by nbari
Modified: 2015-05-19 09:42 UTC (History)
2 users (show)

See Also:


Attachments
shar file for port riak2 (13.80 KB, text/plain)
2015-03-11 11:04 UTC, nbari
no flags Details
fixed riak conf dir $prefix/etc/riak (13.92 KB, text/plain)
2015-03-11 14:21 UTC, nbari
no flags Details
fixed to pass portlint (replace space with tabs) (13.92 KB, text/plain)
2015-03-11 15:17 UTC, nbari
no flags Details
implemented @sample (13.67 KB, application/x-shar)
2015-03-11 18:12 UTC, nbari
no flags Details
build_depends lang/riak-erlang (13.67 KB, text/plain)
2015-03-17 14:04 UTC, nbari
no flags Details
fixed ENV pointing to riak-erlang (13.67 KB, text/plain)
2015-03-17 14:22 UTC, nbari
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description nbari 2015-03-11 11:04:20 UTC
Created attachment 154199 [details]
shar file for port riak2

Bashio currently maintains two versions or riak, 1.4,x and 2.0.x

riak 2 uses solr for searching.

Yokozuna is the new implementation of Riak Search built atop Apache Solr.

In order to properly build riak 2.0.5 a files from a custom solr build from bashio is required which makes difficult to create the port using textproc/apache-solr

riak 2 don't require java or apache-solr to run.

The search feature (yokozuna) is disable by default, but the build requires bashio solr4  files so that i can work as expected when required.
Comment 1 nbari 2015-03-11 14:21:50 UTC
Created attachment 154202 [details]
fixed riak conf dir $prefix/etc/riak

Fixes riak conf dir to be ${prefix}/etc/riak
Comment 2 nbari 2015-03-11 15:17:57 UTC
Created attachment 154204 [details]
fixed to pass portlint (replace space with tabs)

cosmetic change to pass portlint replacing spaces with tabs
Comment 3 nbari 2015-03-11 18:12:56 UTC
Created attachment 154212 [details]
implemented @sample

implemented @sample on the port
Comment 4 nbari 2015-03-17 14:04:46 UTC
Created attachment 154451 [details]
build_depends lang/riak-erlang

port BUILD_DEPENDS on port lang/riak-erlang  

port lang/riak-erglang builds a custom Basho's patched version of Erlang
Comment 5 nbari 2015-03-17 14:22:20 UTC
Created attachment 154455 [details]
fixed ENV pointing to riak-erlang

Fixed port to properly work with port lang/riak-erlang
Comment 6 John Marino freebsd_committer freebsd_triage 2015-03-18 13:43:00 UTC
please explain the reason for having a new port (databases/riak2) instead of updating the old port.

Assume that robak could transfer the maintainership of the port to you if he doesn't want to maintain it.

I'm asking why we should have both versions supported.  is riak2 not backwards compatible?
Comment 7 nbari 2015-03-18 15:13:20 UTC
riak1 is different to riak2 mainly because of the search capabilities, Bashio maintains riak1 and riak2.

Problem with this riak2 is that also uses a custom solr build in order to properly compile the port, something that robak can explain better.

I have no problems helping robak updating,testing or maintaining either ports.
Comment 8 John Marino freebsd_committer freebsd_triage 2015-03-18 15:26:20 UTC
I didn't ask about the difference between version 1 and version 2.

I asked what the justification is for having 2 ports rather than just update the existing databases/riak.
Comment 9 nbari 2015-03-18 15:32:47 UTC
riak1 is different than riak2 therefor users may want to use only riak1 while others may want to use only riak2.

hope this helps answer your question.
Comment 10 John Marino freebsd_committer freebsd_triage 2015-03-18 15:35:10 UTC
I'm sorry, it doesn't.

If riak2 is backwards compatible, having two versions is not justified.
Comment 11 nbari 2015-03-18 15:40:11 UTC
Ok no worries, then, what solution you propose  and in what can I help you?
Comment 12 John Marino freebsd_committer freebsd_triage 2015-03-18 15:52:22 UTC
step 1) Find out if riak2 handles riak1 databases (even if it requires a dump export / import)

step 2) Change this from an "add port" PR to an "update port" PR.  Since Robak is not interested in riak2, you'd need to change the maintainer from him to you and he would have to be agree.  I don't see why he wouldn't though.
Comment 13 John Marino freebsd_committer freebsd_triage 2015-03-18 15:52:58 UTC
P.S.  You aren't "helping me".  I didn't take this PR.   I'm commenting on it.
Comment 14 Bartek Rutkowski freebsd_committer freebsd_triage 2015-03-24 20:29:15 UTC
Riak 1.4.x and 2.x although being the same database, are two different pieces of software with different capabilities and different dependencies, like already mentioned Solr (and not the stock one, that we have in ports, but the one provided by Basho) so this should indeed be a separate port. Given the 2.x version seems to be extremely picky about the deps origin (namely, they all need to come from Basho and cant be stock versions) I have no intention in handling nor maintaining such piece of software.

However, for all the users that can have products using current Riak 1.x port (and for myself) I would still keep it in ports tree until is deprecated and not supported by upstream - so far it is on par with Riak 2.x.
Comment 15 John Marino freebsd_committer freebsd_triage 2015-03-30 08:14:03 UTC
as mentioned in bug 198656 , neither Robak nor I think riak2 is suitable to be built from source based on non-stock versions of multiple dependencies and the policies/attitudes of basho.  Thus we don't support this PR.

However, Basho reportedly does build their own FreeBSD binary packages, thus I would support a port that installs those binaries, one that has no dependencies.
Comment 16 John Marino freebsd_committer freebsd_triage 2015-05-19 09:42:14 UTC
This PR seems dead; nbari doesn't seem to like the idea of wrapping provided binaries so it is at an impasse.