SQL::Statement unusable in major Linux distributions

[Jonathan Yu]

Paul,

On Tue, Nov 3, 2009 at 10:11 PM, Paul Beardsell <paul at beardsell.com> wrote:
> Jonathan,
>
> This bug is reported to exist in all versions tested 1.14 and later.  This
> includes 1.22 recently accepted into Debian unstable and testing.  It
> matters not what I do, I cannot install a version of SQL::Statement that
> works.
>
> But say I could!  Say I could soon download the fixed 1.23 using some of the
> well-known workarounds you describe.  That solves *my* problem.  But we are
> left with the issue of how do we ensure that everyone else knows of the
> bug?  If I report the bug to the last known distributor of Linux Crunx how
> does Debian get to hear of the bug?  How would the maintainer at CPAN get to
> hear of the bug so as to know to provide a fix in 1.23?  That's where your
> argument breaks down - in order to see the fix in 1.23 I need to let the
> maintainer know.

Sure. But as I said (quote):

2. If you install a package from CPAN, then the maintainer is
responsible for it. That makes sense. So if you have issues with the
current version of a module from CPAN, then feel free to bug the
maintainer. If you have issues with an older version you get from
CPAN, then it's up to the upstream people whether or not they consider
your issue a bug, and whether they want to fix it.

>
> If the world were just Debian and CPAN it would work well the way you
> describe.
>
> No, non distro specific bugs must be reported to rt.cpan.org and, as I said,
> this applies to old versions too and I thing RT admin agrees with me (on
> this very narrow point).

You risk alienating the upstream this way, but it is your prerogative,
of course.
>
> Yes, yes, yes, I could fork SQL::Statement but I lack the skills.  We (those
> who want a SQL engine which actually *works* on CSV files) need version
> 0.1020 to be resurrected.  Or 1.15 fixed.  Or 1.22 fixed.  Those are the
> choices.  If you want something quick perhaps only 0.1020 works.  Or Sqlite.

Here are the versions available in our package pool:

http://ftp.debian.org/debian/pool/main/libs/libsql-statement-perl/

Unfortunately, the oldest version we have is:
libsql-statement-perl 1.15-2

I tested this on my system (installing 1.15-2 doesn't work; I don't
think I have oldstable in my apt configuration)

> sudo apt-get install libsql-statement-perl=1.15-3
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  libsql-statement-perl
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 128kB of archives.
After this operation, 438kB of additional disk space will be used.
Get:1 http://ftp.ca.debian.org stable/main libsql-statement-perl 1.15-3 [128kB]

You can always install older versions via CPAN manually too, and in
Debian's case at least, you can also recommend we provide that older
version for compatibility with things. I'm not sure of what other
resolutions we could have; maybe someone else can chime in.
>
> Paul Beardsell
>
>
> 2009/11/4 Jonathan Yu <jonathan.i.yu at gmail.com>
>>
>> Paul:
>>
>> I think you misunderstood my point, and it was probably my mistake in
>> articulating myself. Here is the essential dichotomy as I understand
>> it:
>>
>> 1. If you install a package from a distro which contains a Perl
>> module, then the distro is responsible for maintaining it. If you
>> install a Debian package which is broken, it's Debian's fault. If you
>> install a Ubuntu package which is broken, it's Ubuntu's fault
>> (possibly Debian's fault indirectly, too, of course).
>>
>> 2. If you install a package from CPAN, then the maintainer is
>> responsible for it. That makes sense. So if you have issues with the
>> current version of a module from CPAN, then feel free to bug the
>> maintainer. If you have issues with an older version you get from
>> CPAN, then it's up to the upstream people whether or not they consider
>> your issue a bug, and whether they want to fix it.
>>
>> However, there are many options/workarounds in case you are
>> experiencing a non-distro-specific bug due to an older version of a
>> module available in YOUR distro.
>>
>> 1. Install into /usr/local (in Debian and Ubuntu this is done by
>> default via the CPAN shell). Modules placed there should be given
>> priority over ones installed via your distro (in Debian /usr/local is
>> higher in @INC than /usr/share and /usr/lib, where most other stuff is
>> installed)
>>
>> 2. Install into your homedirectory or something else. local::lib
>> (available on CPAN) is tremendously useful for this purpose, I hear.
>> Actually, it's also available as a Debian package - liblocal-lib-perl.
>>
>> Next, I think it's up to the upstream people as to their maintenance
>> policy. If they have decided, "the newest is the only one we will care
>> about" -- then that's what you get. This is open source; H.Merijn
>> Brand, Jens Rehsack and *many* many (countless!) others contribute
>> their FREE TIME (okay, maybe their $work is just nice) to provide you
>> a product which is FREE (both free as in beer and free as in freedom).
>>
>> Because this is open source, however, you are *always* free to fork a
>> module and continue maintaining it as you choose. Either that, or you
>> can try convincing upstream -- but based on the length of this
>> discussion, it doesn't seem like you've been able to do that thus far.
>>
>> On Tue, Nov 3, 2009 at 9:34 PM, Paul Beardsell <paul at beardsell.com> wrote:
>> [snip]
>> > If I find a bug in a four year old version of a package but that is the
>> > current version that is distributed in every Linux distro then there
>> > needs
>> > to be a central place for the bug report.  Where is that?  It is
>> > rt.cpan.org.  And I believe RT admin agrees (on this narrow point, at
>> > least). That's the position we are in with SQL::Statement
>> Fair enough. You have every right to file a bug and tag it with an
>> older version; however, you're at the mercy of upstream if they decide
>> to consider it a "I won't fix this" bug and reject it. However, you
>> can also submit patches so that others who stumble on your bug report
>> and are in the same position as you can fix theirs, and benefit from
>> your work.
>> >
>> > This bug I have reported to Ubuntu via Launchpad.  At the moment I have
>> > not
>> > reported it formally to Debian as I temporarily only have Woody because
>> > that's the last Debian with a working libsql-statement-perl i.e.
>> > SQL::Statement 0.1020.  I have verified it on Etch and Lenny but that
>> You can always determine what version of a package we have by using
>> the "madison" tool via dak ls:
>>
>> http://qa.debian.org/madison.php -- type any package name on this
>> page, and it will show you the versions available in different
>> releases of Debian. Here is the output for libsql-statement-perl:
>>
>> libsql-statement-perl |     1.15-2 |     etch-m68k | source, all
>> libsql-statement-perl |     1.15-2 |     oldstable | source, all
>> libsql-statement-perl |     1.15-3 |        stable | source, all
>> libsql-statement-perl |     1.22-1 |       testing | source, all
>> libsql-statement-perl |     1.22-1 |      unstable | source, all
>>
>> http://qa.debian.org/madison.php?package=libsql-statement-perl&a=&b=&c=&s=
>>
>> > machine is dead so I cannot report version numbers etc exactly.  I have
>> > reported it to CPAN for the benefit of everyone.  And so the package
>> > maintainer can consider if it applies to the latest version of the
>> > package.
>> > It does and therefore, as it is such a critical bug, the package should
>> > perhaps not be accepted by Debian.  But it has been!  A few days before
>> > my
>> > bug report.  And had I not been so tenacious the bug report would have
>> > remained "rejected" or "deleted", not "open", and you would not know of
>> > it.
>> > Ever.  After a while you would stop including libsql-statement-perl in
>> > Debian because NOBODY uses it BECAUSE IT IS UNUSABLE by anyone who wants
>> > a
>> > simple SQL UPDATE statement to work.
>>
>> I really don't know what to say here. You can always fork it (and
>> Debian users are always able to install an older version from the
>> archive, and pin it there using apt-pinning. Maybe not ideal, but
>> that's a possible "solution", at least until you can get this issue
>> fixed upstream)
>> >
>> > There is a lot of excellent code available from CPAN from a lot of most
>> > dedicated developers/maintainers and testers and documenters and, dare I
>> > say, bug reporters!  Thanks to any of you who read this.  However, it is
>> > *not* ALL of excellent quality, and being shy of saying so can be part
>> > of
>> > the problem.  That doesn't mean to say that some packages are more
>> The CPAN Ratings system, CPAN Testers, CPAN Testing Service (aka
>> Kwalitee), FAIL100, and more are QA initiatives to help fix this. Many
>> people have been working really hard on this particular problem, but
>> everything needs to be in line with CPAN/Perl philosophy; there is
>> more than one way to do it.
>>
>> Just because it doesn't work for you, doesn't mean it doesn't work for
>> other people. I think it's best to keep that in mind.
>>
>> Given the current state of things, I think the onus is on users to
>> consider these easily available bits of information via the various QA
>> pages to determine whether or not the module is worth installing.
>> Different people have different criteria to determine what they
>> consider a "good" vs "crappy" package. CPAN Testers and the Kwalitee
>> metrics provided via CPANTS are intended to help users make informed
>> decisions.
>>
>> More work is forthcoming (particularly CPANHQ) to help make this
>> information more easily available for people.
>>
>> PLEASE do not minimize the work of the aformentioned QA-related
>> projects and THEIR various contributors to nothing. Change is
>> happening, the problem is known, but HELP IS NEEDED. If you think
>> Perl/CPAN QA could be improved, then either "crap or get off the pot"
>> -- these are open projects, and I suggest you look into perhaps
>> contributing to CPANHQ. You could be the next person to help shape the
>> future direction of CPAN, and to help users make informed decisions
>> when looking at modules they want to use for their next projects.
>>
>> I really suggest you channel your attitude in a more productive way.
>> And again, if you can't convince upstream SQL::Statement maintainers
>> that there is a problem, then the only recourse you can really have is
>> to "fork off" (ie, fork your own module).
>>
>> Hopefully this helps you. I don't want to come off as someone flaming
>> your response; on the contrary, I would really like to see your
>> efforts here bear some fruit, even if not directly in SQL::Statement
>> but in other QA-related projects like CPANHQ, CPANTS, etc.
>>
>> Cheers!
>>
>> Jonathan
>>
>> > challenging than others to maintain.  Some maintainers have bravely
>> > taken on
>> > packages which are in a mess and which need lots of work.  Some
>> > maintainers
>> > have an easy life!  Others slog their guts out for no thanks.  And in
>> > their
>> > spare time.  But the quality of the packages and their maintenance does
>> > vary, package to package.
>> >
>> > Paul Beardsell
>> >
>> >
>> > 2009/11/4 Jonathan Yu <jonathan.i.yu at gmail.com>
>> >>
>> >> Hi Paul:
>> >>
>> >> From the perspective of Debian in particular, I have the following
>> >> statement to make.
>> >>
>> >> On Tue, Nov 3, 2009 at 5:49 PM, Paul Beardsell <paul at beardsell.com>
>> >> wrote:
>> >>
>> >> [snip]
>> >> >
>> >> > * It is beneficial to the Perl community (developers and users) that
>> >> > bugs
>> >> > are held centrally. I am sure this is also the position of the Perl
>> >> > community. The discoverer of a bug cannot be responsible for
>> >> > contacting
>> >> > each
>> >> > distro.  Distro maintainers cannot independently triage *all* bugs in
>> >> > all
>> >> > the packages they include.  They need (we need!) "upstream", a
>> >> > central
>> >> > repository.  rt.cpan.org has the facility to record bugs against
>> >> > older
>> >> > but
>> >> > still current versions.  It should be used as I think Jesse Vincent
>> >> > also
>> >> > intended, for the benefit of the wider community, as this central
>> >> > repository.
>> >> >
>> >> [snip]
>> >>
>> >> In Debian, we like to have everything that affects our packages filed
>> >> in our bug tracker (the Debian Bug Tracking System). From time to time
>> >> in the past, we have missed these bugs (ie, not forwarded them
>> >> upstream), and this has been problematic for people. However, our bug
>> >> tracker is entirely open and anyone is free to look at our packages
>> >> and forward relevant issues upstream.
>> >>
>> >> One particular point I'd like to make is that sometimes bugs only
>> >> exist downstream due to some modifications we've made in order to
>> >> package things or for some other reason. As a result, it doesn't seem
>> >> fair to bother the upstream maintainers about issues which are
>> >> Debian-specific, or Fedora-specific, for example.
>> >>
>> >> Therefore, we ask that our users always file bugs against the Debian
>> >> packages; we will coordinate with upstream appropriately to get things
>> >> fixed, taking care to forward the bug and make whatever arrangements
>> >> necessary to fix the package.
>> >>
>> >> In general, the CPAN Request Tracker has been where we forward most of
>> >> our bug reports. Some maintainers do not like to use the RT system,
>> >> and we have to respect their wishes. In that case, we file bugs by
>> >> whatever means the maintainers tell us to in the POD of their
>> >> packages, or otherwise in the RT or via direct mail.
>> >>
>> >> In defense of the SQL::Statement maintainers and all, I think if there
>> >> are critical issues with older releases, they should be brought to the
>> >> attention of each distro. Debian has policies for when things get
>> >> synchronized between unstable <-> testing, and things that can be
>> >> updated in stable. Things like security fixes and critical fixes are
>> >> candidates for patches in stable, however this is the responsibility
>> >> of Debian/Fedora/etc and not of the CPAN Maintainers.
>> >>
>> >> I urge you to let the CPAN maintainers do what they do best -- produce
>> >> good software. Others (including those that package these modules) are
>> >> responsible for distro-specific issues, and I encourage you to file
>> >> bugs in those packages.
>> >>
>> >> Cheers,
>> >>
>> >> Jonathan
>> >
>> >
>
>