Skip Menu |
 

This queue is for tickets about the DBD-ODBC CPAN distribution.

Report information
The Basics
Id: 46944
Status: resolved
Priority: 0/
Queue: DBD-ODBC

People
Owner: Nobody in particular
Requestors: REHSACK [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.21
Fixed in: 1.22_3



Subject: DBD::ODBC doesn't find iodbc correctly (with patch)
Download (untitled) / with headers
text/plain 379b
Hi, sorry that I missed instantly reporting. During packaging DBD::ODBC for pkgsrc (http://www.pkgsrc.org/) I encounter some problems with iodbc and with some interactive feedback. I fixed the iodbc detection and comment out the interactive feedback. For the latter one I suggest using options like DBD::Sybase does - and maybe a dry test, if possible. Thanks in advance, Jens
Subject: patch-aa
Download patch-aa
application/octet-stream 3.1k

Message body not shown because it is not plain text.

On Mon Jun 15 05:06:18 2009, REHSACK wrote: Show quoted text
> Hi, > > sorry that I missed instantly reporting. During packaging DBD::ODBC for > pkgsrc (http://www.pkgsrc.org/) I encounter some problems with iodbc and > with some interactive feedback. > > I fixed the iodbc detection and comment out the interactive feedback. > For the latter one I suggest using options like DBD::Sybase does - and > maybe a dry test, if possible. > > Thanks in advance, > Jens
Thanks Jens. What exactly was wrong with the interactive feedback: - prompt("Press return to continue..."); and what do you mean by "a dry test" like DBD::Sybase? Why did you move unixodbc after iODBC: - $myodbc = 'unixodbc' - if !$myodbc && glob "$odbchome/lib/libodbc.*"; - $myodbc = 'iodbc' if !$myodbc && ((glob "$odbchome/*iodbc*") || (glob "$odbchome/lib/*iodbc*")); + $myodbc = 'unixodbc' + if !$myodbc && glob "$odbchome/lib/libodbc.*"; + $myodbc = 'empress' if !$myodbc && glob "$odbchome/lib/libempodbc.*"; Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #46944] DBD::ODBC doesn't find iodbc correctly (with patch)
Date: Mon, 15 Jun 2009 09:31:24 +0000
To: bug-DBD-ODBC [...] rt.cpan.org
From: Jens Rehsack <rehsack [...] web.de>
Download (untitled) / with headers
text/plain 1.9k
Martin J Evans via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=46944 > > > On Mon Jun 15 05:06:18 2009, REHSACK wrote:
>> Hi, >> >> sorry that I missed instantly reporting. During packaging DBD::ODBC for >> pkgsrc (http://www.pkgsrc.org/) I encounter some problems with iodbc and >> with some interactive feedback. >> >> I fixed the iodbc detection and comment out the interactive feedback. >> For the latter one I suggest using options like DBD::Sybase does - and >> maybe a dry test, if possible. >> >> Thanks in advance, >> Jens
> > Thanks Jens. > > What exactly was wrong with the interactive feedback: > > - prompt("Press return to continue...");
Packaging often runs non-interactive. pkgsrc has the philosophy that all switches for the packages has to be made in mk.conf - I can't fight against the packaging system here. Show quoted text
> and what do you mean by "a dry test" like DBD::Sybase?
No - DBD::Sybase doesn't provide a dry test, but the provide a Getopt::Long featured list of switches which allow to answer all "prompt" requests by the packager. A "dry test" is another feature - as packager I usually don't want to install a full ODBC environment including configuring test databases etc. for a "make test" run. But other native interfaces (e.g. DBD::Oracle etc.) doesn't support tests without databases, too. So maybe forget the "dry test" idea :) Show quoted text
> Why did you move unixodbc after iODBC: > > - $myodbc = 'unixodbc' > - if !$myodbc && glob "$odbchome/lib/libodbc.*"; > - > $myodbc = 'iodbc' > if !$myodbc && ((glob "$odbchome/*iodbc*") || > (glob "$odbchome/lib/*iodbc*")); > > + $myodbc = 'unixodbc' > + if !$myodbc && glob "$odbchome/lib/libodbc.*"; > + > $myodbc = 'empress' > if !$myodbc && glob "$odbchome/lib/libempodbc.*";
iodbc provides a libodbc.${shlibext}, too. So unixodbc detection will succeed there, even if iodbc is installed. Show quoted text
> Martin
Jens
Download signature.asc
application/pgp-signature 834b

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 2.6k
On Mon Jun 15 05:40:54 2009, rehsack@web.de wrote: Show quoted text
> > What exactly was wrong with the interactive feedback: > > > > - prompt("Press return to continue...");
> > Packaging often runs non-interactive. pkgsrc has the philosophy that all > switches for the packages has to be made in mk.conf - I can't fight
against Show quoted text
> the packaging system here.
But prompt only prompts if Makefile.PL is running interactively - see prompt in ExtUtils::MakeMaker: If "prompt()" detects that it is not running interactively and there is nothing on STDIN or if the PERL_MM_USE_DEFAULT environment variable is set to true, the $default will be used without prompting. This prevents automated processes from blocking on user input. This all works fine for all those people doing DPAN::Reporter::Smoker etc. prompt is the recognised way of doing this. Show quoted text
> > and what do you mean by "a dry test" like DBD::Sybase?
> > No - DBD::Sybase doesn't provide a dry test, but the provide a
Getopt::Long Show quoted text
> featured list of switches which allow to answer all "prompt" requests
by the Show quoted text
> packager.
There are no prompt requests in DBD::ODBC only calls to prompt to make sure you've read important information (see above). I thought DBD::ODBC already had switches for the rest (NONE of which are prompted for): -o to set ODBCHOME -u for unicode/non unicode -g for debug Show quoted text
> A "dry test" is another feature - as packager I usually don't want to > install a full ODBC environment including configuring test databases etc. > for a "make test" run. But other native interfaces (e.g. DBD::Oracle etc.) > doesn't support tests without databases, too. So maybe forget the "dry
test" Show quoted text
> idea :)
The dry test works with DBD::ODBC if you don't define DBI_DSN. Look at the hundreds of cpan smoker test results for DBD::ODBC. These all a) run non-interactively but the prompt knows this and b) all succeed but don't actually run any database tests. Show quoted text
>
> > Why did you move unixodbc after iODBC: > > > > - $myodbc = 'unixodbc' > > - if !$myodbc && glob "$odbchome/lib/libodbc.*"; > > - > > $myodbc = 'iodbc' > > if !$myodbc && ((glob "$odbchome/*iodbc*") || > > (glob "$odbchome/lib/*iodbc*")); > > > > + $myodbc = 'unixodbc' > > + if !$myodbc && glob "$odbchome/lib/libodbc.*"; > > + > > $myodbc = 'empress' > > if !$myodbc && glob "$odbchome/lib/libempodbc.*";
> > iodbc provides a libodbc.${shlibext}, too. So unixodbc detection will > succeed there, even if iodbc is installed.
So if I do this it will work nicely for iODBC (a minority of users) but it will break unixODBC (the majority of users). I think a different solution is in order. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #46944] DBD::ODBC doesn't find iodbc correctly (with patch)
Date: Mon, 15 Jun 2009 17:46:04 +0000
To: bug-DBD-ODBC [...] rt.cpan.org
From: Jens Rehsack <rehsack [...] web.de>
Download (untitled) / with headers
text/plain 3.2k
Martin J Evans via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=46944 > > > On Mon Jun 15 05:40:54 2009, rehsack@web.de wrote: >
>>> What exactly was wrong with the interactive feedback: >>> >>> - prompt("Press return to continue...");
>> Packaging often runs non-interactive. pkgsrc has the philosophy that all >> switches for the packages has to be made in mk.conf - I can't fight
> against
>> the packaging system here.
> > But prompt only prompts if Makefile.PL is running interactively - see > prompt in ExtUtils::MakeMaker: > > If "prompt()" detects that it is not running interactively and there is > nothing on STDIN or if the PERL_MM_USE_DEFAULT environment variable is > set to true, the $default will be used without prompting. This prevents > automated processes from blocking on user input. > > This all works fine for all those people doing DPAN::Reporter::Smoker > etc. prompt is the recognised way of doing this.
But what if the user does a "pkg_rolling-replace -u"? There is a STDIN but (s)he expects that the updates are running unattended. I try to use the PERL_MM_USE_DEFAULT environment variable - I neither know prompt() nor PERL_MM_USE_DEFAULT ;) Show quoted text
>>> and what do you mean by "a dry test" like DBD::Sybase?
>> No - DBD::Sybase doesn't provide a dry test, but the provide a
> Getopt::Long
>> featured list of switches which allow to answer all "prompt" requests
> by the
>> packager.
> > There are no prompt requests in DBD::ODBC only calls to prompt to make > sure you've read important information (see above). > > I thought DBD::ODBC already had switches for the rest (NONE of which are > prompted for): > > -o to set ODBCHOME > -u for unicode/non unicode > -g for debug
Seen \o/ Show quoted text
>> A "dry test" is another feature - as packager I usually don't want to >> install a full ODBC environment including configuring test databases etc. >> for a "make test" run. But other native interfaces (e.g. DBD::Oracle etc.) >> doesn't support tests without databases, too. So maybe forget the "dry
> test"
>> idea :)
> > The dry test works with DBD::ODBC if you don't define DBI_DSN. Look at > the hundreds of cpan smoker test results for DBD::ODBC. These all a) run > non-interactively but the prompt knows this and b) all succeed but don't > actually run any database tests.
Yes. The longer I think about it, the more I see what nonsense the "improved dry test" request must be. Show quoted text
>>> Why did you move unixodbc after iODBC: >>> >>> - $myodbc = 'unixodbc' >>> - if !$myodbc && glob "$odbchome/lib/libodbc.*"; >>> - >>> $myodbc = 'iodbc' >>> if !$myodbc && ((glob "$odbchome/*iodbc*") || >>> (glob "$odbchome/lib/*iodbc*")); >>> >>> + $myodbc = 'unixodbc' >>> + if !$myodbc && glob "$odbchome/lib/libodbc.*"; >>> + >>> $myodbc = 'empress' >>> if !$myodbc && glob "$odbchome/lib/libempodbc.*";
>> iodbc provides a libodbc.${shlibext}, too. So unixodbc detection will >> succeed there, even if iodbc is installed.
> > So if I do this it will work nicely for iODBC (a minority of users) but > it will break unixODBC (the majority of users). I think a different > solution is in order.
Well - why does it break unixODBC? If "$odbchome/lib/*iodbc*" doesn't match, "$odbchome/lib/libodbc.*" is tried. Show quoted text
> Martin
Jens
Download signature.asc
application/pgp-signature 834b

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 726b
I have applied a variation on your patch. It does not include removing the prompt (although I'd be interested in your findings using PERL_MM_USE_DEFAULT), and I didn't change the ordering of unixodbc/iodbc though as you state it should not make any difference. I do not intend releasing this immediately since I have a pile of changes waiting in the wings to finish off. I do not have iODBC to test against and am frankly quite surprised that anyone is using it over unixODBC. However, if you would like to test the patched version please let me know by mailing my cpan address mjevans dot cpan dot org and I'll send you a copy. Thanks for your contribution to the DBD::ODBC project. Martin -- Martin J. Evans Wetherby, UK
Subject: Re: [rt.cpan.org #46944] DBD::ODBC doesn't find iodbc correctly (with patch)
Date: Tue, 16 Jun 2009 08:10:14 +0000
To: bug-DBD-ODBC [...] rt.cpan.org
From: Jens Rehsack <rehsack [...] web.de>
Download (untitled) / with headers
text/plain 1.2k
Martin J Evans via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=46944 > > > I have applied a variation on your patch. It does not include removing > the prompt (although I'd be interested in your findings using > PERL_MM_USE_DEFAULT),
agreed Show quoted text
> and I didn't change the ordering of unixodbc/iodbc > though as you state it should not make any difference.
Incorrect! It makes a difference! Both - iodbc and unixodbc - creates a file $prefix/lib/libodbc.${shlib}. While it's possible to prove the existence of lib/libiodbc.${shlib} first to ensure the installed libodbc.${shlib} belongs to iodbc, it's not possible with the current logic to first find unixodbc and later iodbc. Show quoted text
> I do not intend releasing this immediately since I have a pile of > changes waiting in the wings to finish off. I do not have iODBC to test > against
You can use pkgsrc, if you want (http://www.pkgsrc.org/). It works on nearly any OS and provides both, unixodbc and iodbc. Show quoted text
> and am frankly quite surprised that anyone is using it over > unixODBC. However, if you would like to test the patched version please > let me know by mailing my cpan address mjevans dot cpan dot org and I'll > send you a copy.
Sure - send me a copy to sno@netbsd.org Show quoted text
> Thanks for your contribution to the DBD::ODBC project.
Best regards, Jens
Download signature.asc
application/pgp-signature 834b

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 944b
On Tue Jun 16 04:19:47 2009, rehsack@web.de wrote: Show quoted text
> Martin J Evans via RT wrote:
> > and I didn't change the ordering of unixodbc/iodbc > > though as you state it should not make any difference.
> > Incorrect! It makes a difference! > Both - iodbc and unixodbc - creates a file $prefix/lib/libodbc.${shlib}. > While it's possible to prove the existence of lib/libiodbc.${shlib}
first to Show quoted text
> ensure the installed libodbc.${shlib} belongs to iodbc, it's not possible > with the current logic to first find unixodbc and later iodbc.
Appologies, I missed your point originally - I have changed this to the way you had it. I had not appreciated iODBC installed a libodbc.xx now as well as a libiodbc.xx. Show quoted text
> You can use pkgsrc, if you want (http://www.pkgsrc.org/). It works on
nearly Show quoted text
> any OS and provides both, unixodbc and iodbc.
I'll take a quick look at that. A copy is on its way to you later today. Martin -- Martin J. Evans Wetherby, UK


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.