This is a port of the xapian-full gem. It contains a copy of Xapian 1.2.3 bundled within and is therefore independent of any system installed copy of Xapian. I had some issues with the rubygem automatic plist where several symlinks were not cleaned up after deinstall. A manual plist with some 'unlink' commands seems to do the job nicely, however if there is a better way please advise. Please note that building the gem takes some time because of the full xapian build that happens behind the scenes. Ported as a dependency of another gem I am working on. How-To-Repeat: n/a
Responsible Changed From-To: freebsd-ports-bugs->ruby ruby@ wants this port PRs (via the GNATS Auto Assign Tool)
State Changed From-To: open->suspended suspend
Responsible Changed From-To: ruby->brix Over to maintainer
Responsible Changed From-To: brix->pgollucci I will take it.
State Changed From-To: suspended->feedback Request Feedback: see ports/164460, please update to use the system copy
Hi Philip, I think you may have missed that this gem contains a copy of Xapian and doesn't therefore use the 'system' copy. At present the Gem is using a slightly older version of 'Xapian' (1.2.3) than the 'system' will be at after your PR (164460). The gem has no dependency on the system copy (xopy installed into Gem dirs). Opinion on that as a good/bad idea will I'm sure vary from person to person, but this gem was used as a dependency of something I was porting some months ago hence the PR. So did you mean that you want the upstream Gem author to look at migrating to Xapian 1.2.7 before considering putting it in ports? I don't believe the Gem has been updated since I submitted the PR. Could you just clarify -Eric
On 01/25/12 19:19, Eric wrote: > Hi Philip, > > I think you may have missed that this gem contains a copy of Xapian and > doesn't therefore use the 'system' copy. At present the Gem is using a > slightly older version of 'Xapian' (1.2.3) than the 'system' will be at > after your PR (164460). The gem has no dependency on the system copy (xopy > installed into Gem dirs). Opinion on that as a good/bad idea will I'm sure > vary from person to person, but this gem was used as a dependency of > something I was porting some months ago hence the PR. > > So did you mean that you want the upstream Gem author to look at migrating > to Xapian 1.2.7 before considering putting it in ports? I don't believe the > Gem has been updated since I submitted the PR. > > Could you just clarify Rather I meant ideally we should patch the gem to use the system one. 1.2.3 should be 99% compat with 1.2.7. -- ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Director Operations, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching.
I see, I'm not sure I totally agree with that approach. I think changing the expected functionality (okay in reality the change is liable to be very modest) of this Gem library from the author expectations isn't the right approach. There are already other Gems (not sure if they are in ports) that bind to the system (if installed) Xapian install, the expectation of this Gem is that it's "self contained". I think it's opening up an unneeded maintenance issue to essentially create a private FreeBSD only fork of this Gem which may appear to the casual user to be the original. Regards Eric
State Changed From-To: feedback->open Feedback received
State Changed From-To: open->feedback Request Feedback: http://people.freebsd.org/~pgollucci/FreeBSD/logs/9-CURRENT-amd64/rubygem-xapian-full-1.2.3.log
State Changed From-To: feedback->closed submitter timeout on tb failure (32 days)