Hi Steve, to be honest: I did not know that this was even possible. I would gladly apply this to upstream Soprano if you could provide a generic non-Debian specific patch.
Also did you test this? Did you run the Virtuoso unit test? Cheers, Sebastian On 03/06/2012 08:47 AM, Steve Langasek wrote: > Hi Sebastian, nice to meet you! > > On Tue, Mar 06, 2012 at 01:34:45AM +0100, Pino Toscano wrote: > >> Alle martedì 6 marzo 2012, Steve Langasek ha scritto: >>> I'm surprised to say that after sitting on this bug for far too long, >>> it turns out that it's trivial to fix. Although it had been >>> reported that soprano would not work with unixodbc, once I actually >>> installed virtuoso, which the soprano test suite silently depends >>> on, I get the same results from test/virtuosobackendtest when built >>> against either iODBC or UnixODBC. > >> I remember Sebastian Trueg (main soprano upstream) strongly recommending >> against using unixODBC (e.g. in [2], just last September), so I'm not >> sure whether this switch would break anything in the semantic desktop >> stack. >> (Disclaimer: I don't use Nepomuk myself.) > >> Sebastian, what is the current status of soprano wrt unixODBC/iODBC? >> Which problems would result in using unixODBC? > >> [2] http://trueg.wordpress.com/2011/09/22/about-strigi-soprano-virtuoso- >> clucene-and-libstreamanalyzer/ > > Right, so I've read the comment in that blog entry about needing libiodbc > because of RDF extensions. But I've reviewed the libiodbc source, and can't > find any evidence that such extensions exist - there's a single RDF define > in the iodbcext.h header, but a copy of this header is shipped in the > soprano source and there are no uses of the define anyway. As best as I can > tell, the only extensions are in the virtuoso driver, which libiodbc2 merely > passes the requests through to - and unixodbc would appear to do the very > same. > > The one thing I have found that's different between iODBC and UnixODBC (but > not represented in the previous patch) is that UnixODBC will not allow > look-up of a driver by filename alone; it requires that the filename match > the filename for a driver registered with odbcinst.ini. This seems like a > feature that we could patch into UnixODBC easily enough if needed. (And > apparently there was something wrong with my previous testing that I didn't > catch this.) > > However, I wonder why it makes sense for soprano to use a driver manager at > all, given that it appears soprano can *only* use the virtuoso driver as a > backend. Wouldn't it be simpler to call into the virtuoso driver directly > and omit the driver manager, on Unix? > > Attached is a revised patch to the Debian that implements the above > proposal. Since UnixODBC is no longer involved (except as a provider of the > sql.h header) there should not be any compatibility issues here. It may not > be portable to non-Linux systems, but maybe it would be an acceptable distro > patch, Pino? > >>> I'm happy to upload this as an NMU if you would like. It's probably >>> worth an upload ASAP rather than waiting for 2.7.5+dfsg.1-1 to >>> migrate to testing, since it's hard to have usable ODBC drivers for >>> soprano until it's fixed. > >> We're currently just started our KDE 4.7 transition, which includes also >> a soprano update from 2.6 to 2.7; if possible, I think IMHO it would be >> desiderable to wait for such dependency change, in case, after the >> transition is over (hopefully in two weeks, if everything goes fine). >> Would this timeframe suit you? > > I think it makes perfect sense to not upload this change until we're > confident it's not going to be a problem for the transition. > > Cheers, -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f55cf2c.6020...@kde.org
