SQL::Statement unusable in major Linux distributions

Jonathan Yu jonathan.i.yu at gmail.com
Wed Nov 4 02:53:15 UTC 2009


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
>
>



More information about the pkg-perl-maintainers mailing list