Hi All, When are the XS-based Perl bindings going to be deprecated in favour of the SWIG bindings? Please remove the dead RHEL RPMs from: http://xapian.org/download I've built RPMs for RHEL5/CentOS5 (with a different signing key) here: http://rpm.eprints.org/xapian/5/ RHEL4 is eol and shouldn't be used. For my own convenience I have written an RPM for the repository: rpm -ivh http://rpm.eprints.org/xapian/5/noarch/rpm-eprints-org-xapian-5-1.noarch.rpm yum update yum install xapian-core Which will tie users to rpm.eprints.org but the RPM could be trivially rewritten to xapian.org. (NB CentOS expects /5/ whereas RHEL expects /5Server/) All the best, Tim.
On Mon, Nov 22, 2010 at 10:39:47AM +0000, Tim Brody wrote:> When are the XS-based Perl bindings going to be deprecated in favour of > the SWIG bindings?A good question, but I'm not sure we have an answer yet. If we can make the SWIG bindings a perfect drop-in replacement, I think we can just deprecate the XS ones at that point, and remove them once we are pretty confident that we've shaken out any remaining issues. If user code needs much adjusting (worse if it can't be written to work with both cleanly) then I think we probably should deprecate in the next release series, and recommend the SWIG ones for new projects (and people who like migrating their code) until then, If we're somewhere between, I guess we need to think about the pain to users vs the maintenance overhead. If both are going to coexist for long, I guess we need to think about making sure it is feasible to co-install them (so you can run something wanting the XS ones and something wanting the SWIG ones on the same machine).> Please remove the dead RHEL RPMs from: > http://xapian.org/download > > I've built RPMs for RHEL5/CentOS5 (with a different signing key) here: > http://rpm.eprints.org/xapian/5/ > RHEL4 is eol and shouldn't be used.Hmm, RedHat say otherwise: http://www.redhat.com/f/pdf/summit/tburke_1050_rhel_roadmap.pdf customer issues of all severity, proactive security, limited hardware enablement, performance enhancements to enable long-term viability as a virtualized guest on RHEL5 & 6 According to that, even RHEL3 isn't EOL yet! But if nobody wants to maintain such packages (or even fund someone to do it), it's kind of irrelevant what the status of the OS is.> For my own convenience I have written an RPM for the repository: > > rpm -ivh > http://rpm.eprints.org/xapian/5/noarch/rpm-eprints-org-xapian-5-1.noarch.rpm > yum update > yum install xapian-coreOK, I've updated the download page with this. If the wording is wrong or bad, please send a patch.> Which will tie users to rpm.eprints.org but the RPM could be trivially > rewritten to xapian.org.I'm happy to do whatever is easier for you to maintain.> (NB CentOS expects /5/ whereas RHEL expects /5Server/)So do the instructions above work only for CentOS? Cheers, Olly
On Tue, 23 Nov 2010 05:22:38 -0000, Olly Betts <olly at survex.com> wrote:> On Mon, Nov 22, 2010 at 10:39:47AM +0000, Tim Brody wrote: >> When are the XS-based Perl bindings going to be deprecated in favour of >> the SWIG bindings? > > A good question, but I'm not sure we have an answer yet. > > If we can make the SWIG bindings a perfect drop-in replacement, I think > we can just deprecate the XS ones at that point, and remove them once we > are pretty confident that we've shaken out any remaining issues.I'm unsure how you can test the above without writing a unit test for every feature. It "works for me" but then I had to rewrite my code to use the network connection stuff anyway. Otherwise, there are a couple of "FIXMEs" in regard to memory leaks in SWIG? What else is there to do?>> Please remove the dead RHEL RPMs from: >> http://xapian.org/download >> >> I've built RPMs for RHEL5/CentOS5 (with a different signing key) here: >> http://rpm.eprints.org/xapian/5/ >> RHEL4 is eol and shouldn't be used. > > Hmm, RedHat say otherwise: > > http://www.redhat.com/f/pdf/summit/tburke_1050_rhel_roadmap.pdf > > customer issues of all severity, proactive security, limited hardware > enablement, performance enhancements to enable long-term viability > as a > virtualized guest on RHEL5 & 6 > > According to that, even RHEL3 isn't EOL yet! > > But if nobody wants to maintain such packages (or even fund someone to do > it), it's kind of irrelevant what the status of the OS is.Hmm, well there's no harm in leaving the packages online but flag them as unsupported/out of date. I'm about to retire my last server running RHEL4 and it's a long time since I even tried compiling xapian on it.>> For my own convenience I have written an RPM for the repository: >> >> rpm -ivh >> http://rpm.eprints.org/xapian/5/noarch/rpm-eprints-org-xapian-5-1.noarch.rpm >> yum update >> yum install xapian-core > > OK, I've updated the download page with this. If the wording is wrong or > bad, please send a patch.To get source RPMs this should work (yumdownloader is provided by yum-utils): $ yumdownloader --source xapian-core $ yumdownloader --source xapian-bindings $ yumdownloader --source xapian-omega $ yumdownloader --source libuuid-devel (libuuid was a new requirement in 1.2 but isn't available in RHEL5?)>> Which will tie users to rpm.eprints.org but the RPM could be trivially >> rewritten to xapian.org. > > I'm happy to do whatever is easier for you to maintain."rpm.eprints.org" will exist for as long as I'm here (in work, not this planet). Bandwidth is paid for by UK taxpayers ...>> (NB CentOS expects /5/ whereas RHEL expects /5Server/) > > So do the instructions above work only for CentOS?I sym-linked so both will work. I'm just saying it's a "gotcha" for CentOS should you post the RPMs to xapian.org. -- All the best, Tim.
On Tue, 23 Nov 2010 09:59:57 -0000, Tim Brody" <tdb2 at ecs.soton.ac.uk> wrote:> (libuuid was a new requirement in 1.2 but isn't available in RHEL5?) >It's available in EPEL 5 : http://download.fedora.redhat.com/pub/epel/5/SRPMS/repoview/uuid.html Maybe this helps ? Fabrice
On Tue, 23 Nov 2010 22:38:59 -0000, Olly Betts <olly at survex.com> wrote:> On Tue, Nov 23, 2010 at 11:12:46PM +0800, Fabrice Colin wrote: >> On Tue, 23 Nov 2010 09:59:57 -0000, Tim Brody" <tdb2 at ecs.soton.ac.uk> >> wrote: >> > (libuuid was a new requirement in 1.2 but isn't available in RHEL5?) >> > >> It's available in EPEL 5 : >> http://download.fedora.redhat.com/pub/epel/5/SRPMS/repoview/uuid.html >> >> Maybe this helps ? > > That's a different libuuid, which I think has an incompatible API (sigh). > > Tim: libuuid used to be part of e2fsprogs - so e2fsprogs-devel is what > you > probably need to build against on older RPM-based systems (INSTALL does > mention this, but only in the context of Fedora).I failed to reply to the list. Yes, the libuuid-devel package I provide Requires: e2fsprogs-devel and Provides: libuuid-devel as it is only a package naming issue. AFAIK there is no way with RPM to say package A OR package B. /Tim.
On Wed, Nov 24, 2010 at 08:36:38AM -0000, Tim Brody wrote:> I failed to reply to the list. Yes, the libuuid-devel package I provide > Requires: e2fsprogs-devel and Provides: libuuid-devel as it is only a > package naming issue.Ah, neat.> AFAIK there is no way with RPM to say package A OR package B.That was my conclusion when I looked before updating the build dependency from e2fsprogs-devel to libuuid-devel (I concluded it was better to use the one which worked with the majority of systems). Cheers, Olly