Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev
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,
Reply to: