https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40304 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- (In reply to Jake Deery from comment #4)
Thanks for looking. If this is indeed a problem, Debian packages will also have this broken behaviour. Perhaps this isn't an issue, as Debian packages only go on Debian systems, but nonetheless, perhaps it wouldn't hurt fixing this in both places?
(In reply to Jake Deery from comment #6)
That's that change implemented. I've put /usr/lib64/idzebra-2.0/modules first in the sequence, as most folk will be running x86-64, and so it makes sense for Zebrasrv to search there first.
Tested on ARM64 and x86-64. If anyone has a MIPS or POWERPC platform lying around, it would be great to get a thumbs up from you folk too – though, it isn't essential at this stage.
Sorry I should've been more precise before. On 64bit Debian/Ubuntu, you'll find the Zebra modules in /usr/lib/x86_64-linux-gnu/idzebra-2.0/modules/. On 64bit OpenSUSE/SLES (and maybe the Red Hat systems), you'll find them in /usr/lib64/idzebra-2.0/modules/. So the Debian packages didn't have broken behaviour, since - as you say - they'd only be on Debian-based systems. So it would make sense for them to have Debian-specific paths. Your patch that I failed removed /usr/lib64 from the generic Zebra conf, which would create a regression on non-Debian-based systems. I won't fail this latest patch, but you might want to consider not including /usr/lib64 in the Debian package conf (I like the idea of using /usr/lib/x86_64-linux-gnu/idzebra-2.0/modules first in the modulePath config though - as you say it makes sense to search there first.). But the ones in the "./etc" path should support everything since they could be deployed anywhere. -- You are receiving this mail because: You are watching all bug changes.