SQL::Statement unusable in major Linux distributions

Mon Oct 26 10:25:05 UTC 2009

I do not have the up to date skill set to do quite a lot of what you
suggest.  I'm much more an applications programmer than a perl maintainer.
I too have provided code for free, but I fail to see the substance in the
point you are making.  Perhaps the principle reward for programming
(cooking, writing, painting, making music) is an audience, an appreciative
audience.

The oppotunity for a larger appreciative audience is certainly lost.  By far
the most people who have S:S on their computers who have tried to use it
must just think it is rubbish.  The only widely visible versions of S:S do
not work.  Why this is a matter of indifference to those involved in S:S
escapes me.  Could it be (mischievous quetion warning) that some would
rather be in charge of something small and seemingly broken than be swept
aside in the stampede of eager users turned maintainers?

One of the things that you think we should do, encouraging distro
maintainers to include later versions of SQL::Statement, is best done by
allowing me to post a critical bug at CPAN against the version of
SQL::Statement they all include in their distro's.  That would flag the
issue to them.  I ask you to intercede and to ask Jens to leave my bug
report alone, if he won't address it.

You *do* have the environment available to run my test code.  It's very
short and sweet.  Please do so, it's attached to the bug report.

Paul Beardsell
Paul at Beardsell.com

2009/10/26 H.Merijn Brand <h.m.brand at xs4all.nl>

> On Mon, 26 Oct 2009 09:05:01 +0000, Paul Beardsell <paul at Beardsell.com>
> wrote:
>
> > Please see sql-statement bug 50788 which
> > shows several versions of  SQL::Statement to be
> > unusable.  E.g. version 1.15.  It is this version
> > of SQL::Statement which exists in many GNU/Linux
> > distributions including Debian oldstable, stable and
> > testing (and derivatives); Hardy, Intrepid, Jaunty
> > and Karmic (i.e. all recent and current and the
> > forthcoming releases of) Ubuntu (and derivatives);
> > the more recent releases of Redhat (and derivatives)
> > and Suse (and derivatives).
>
> SQL::Statement 1.15 is dead. Dead as a doornail, and will not be
> referred to for fixes. Forget *anything* below 1.22 unless you can
> prove something still worked in 1.15 and does not in 1.22 and you
> have both code and data to show us why.
>
> If you tell the module maintainers that the distributions you mention
> do not update to more recent versions of your favourite modules,
> contact the distribution managers to update their modules. We, as
> module authors, already fixed things, and we certainly do not control
> the behaviour of those that make distribution updates available.
>
> Sorry. You cannot blame us.
>
> OpenSuSE indeed still ships perl-SQL-Statement-1.15-1.72, but it is not
> up to us to *force* them to make the decision to replace that with what
> we already fixed. We should not be your target of complaint!
>
>
> I personally use SQL::Statement-1.22 + DBD::CSV-0.25 on
> DBI-1.609 on a *DAILY* basis in *PRODUCTION* code for
> converting CSV to Postgres. So statements as "unusable"
> do not apply. BTW I am on OpenSUSE 11.0 and 11.1, but for
> the reasons you mention, I never use system perl (neither
> on other distributions of *nix like HP-UX or AIX)
>
> $ perl -MV=DBI,DBD::CSV,SQL::Statement
> DBI
>        /pro/lib/perl5/site_perl/5.10.1/x86_64-linux/DBI.pm: 1.609
> DBD::CSV
>        /pro/lib/perl5/site_perl/5.10.1/DBD/CSV.pm: 0.25
> SQL::Statement
>        /pro/lib/perl5/site_perl/5.10.1/SQL/Statement.pm: 1.22
>
> CSV as a database is not the way to create applications
> that need speed or need low memory footprints or need
> full ANSI-SQL support. If you need either of those, do
> convert CSV to SQLite or postgresql (or another database
> of your preference that does support all of your needs).
>
> In the DBI/DBD world,
> * CSV does not support types (beyond NULL, integer and char)
> * CSV does not support links (referential integrity)
> * CSV does not support speed
> * CSV does not support data dictionary persistence
>
> > The later versions of SQL::Statement are not available
> > for ready installation into any of these Linux
>
> There are a lot of references on the internet on how to install modules
> in your *own* userspace that overrule modules in system space
>
> $PERL5LIB is your friend
>
> > environments by ordinarily competent Linux users.
>
> "competent" implies people know how to set a single environment variable
>
> > Even for the distro maintainers these latest releases
> > are very disruptive (ripple on effects etc) to install
> > owing to numerous dependencies on very new code.
>
> so?
>
> > Similarly older versions of SQL::Statement known not
> > to suffer from bug 50788 are also not available for
> > anything but very difficult if not nearly impossible
> > installation into any recent release of these Linux
> > distro.  E.g. 0.1020 does not suffer from this bug
> > and 0.1020 was std in Debian Woody but Woody is no
> > longer readily downloadable.
>
> We do not refer to anything older than 1.22 thanks
>
> > Consequently, to all intents and purposes
> > SQL::Statement is *dead* in the Linux (distro)
>
> far from ...
>
> > world as it can not have any serious use in its
> > currently (readily) available incarnations owing to
> > the existence of at least one critical bug in S:S.
> >
> > Why?  Why is there no usable version of SQL::Statement
> > out there for (less-than-uber-techie) (common) Linux
> > (distro) users?
>
> Again, don't ask us, ask the linux distribution people.
>
> > For a package to be used it must be reliable and
> > available.
>
> From our perspective it is.
>
> > If(!) there are reliable versions they are not (easily)
> > available.
>
> Not our problem, as we think CPAN *is* easy.
>
> $ cpan SQL::Statement
>
> > What a pity!  SQL::Statement was a great package
>
> it still is. Better even, as Jens took over, functionality grew.
>
> > uniquely allowing SQL to be used on CSV files.
>
> Better, I worked together with Jens to make SQL::Statement
> support the new needs for DBD::CSV so *I* could use it for my daily
> work. We will admit there are still a few black spots or minor nags and
> inconveniences, but it does meet my needs now.
>
> The toolchain for DBD::CSV is more complicated than for say DBD::Pg,
> but I can say I am proud on what we have achieved. The fact that you
> need newer versions of modules than what you have readily available
> only proves that we work (very) hard to make it work as it should work.
>
> > Was.  Now it is broken.
>
> Was. Now it is fixed.
>
> > The world needs, we need, *I* need SQL on CSV files.
>
> Then install DBI-1.609 or newer, SQL::Statement 1.22 or newer and
> DBD::CSV 0.25 or newer. We cannot help you if you decide to keep living
> in the past.
>
> > I very strongly suggest that one of three things
> > be done.
> >
> > (1) If there exists a stable and usable version of
> > SQL::Statement after the known-to-be-broken 1.15 then
> > this must be pushed at the Linux distro maintainers.
>
> I urge you to take actions to make this happen!
>
> > There must be reasons why *no* popular Linux distro
> > has accepted any version after 1.15.
>
> We'd like to know. They never contacted us.
>
> > I know not what all
> > these may be but I suggest but I suggest the
> > very recent version 1.22 is very difficult to install
> > into a working environment or into current Linux
> > distros because of numerous dependencies on some very
> > new code.  Because 1.22 is difficult to install it
> > has practically zero users and I suggest therefore we
> > do not actually know for sure it is a good version!
> > A backport of a recent S:S version such as 1.22 to
> > an earlier Perl environment is needed so that it can
> > be installed without having to upgrade much of one's
> > whole Perl environment.  Then we can get it into the
> > distros, and get some users.
>
> But again, not our problem.
>
> > *or*
> >
> > (2) Forward-port a known to be good version of
> > SQL::Statement such as one of the pre 1.0 versions.
> > I can vouch for 0.1020-2 as found in Debian Woody.
>
> No.
>
> > *or*
> >
> > (3) Fix 1.15.
>
> No.
>
> > OK, so now shoot the messenger.  :-)
>
> Is that an actual option?
>
> Remember that CPAN is built and maintained by people on a voluntary
> basis in our free time (FWIW I quite often would prefer to go skiing
> than to maintain Text::CSV_XS). We are not being paid. Neither to code,
> nor to fix bugs. If you think you are able to make all of this better,
> you should do so by supplying patches. Patches to *recent* versions of
> the module. All patches (except maybe for documentation) should be
> accompanied by new test cases that provide proof.
>
> > Paul Beardsell
>
> --
> H.Merijn Brand  http://tux.nl      Perl Monger  http://amsterdam.pm.org/
> using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
> 11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
> http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
> http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20091026/7d8d5837/attachment-0001.htm>