Skip Menu |
 

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

Report information
The Basics
Id: 88873
Status: open
Priority: 0/
Queue: DBD-XBase

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

Bug Information
Severity: (no value)
Broken in:
  • 1.00
  • 1.01
  • 1.02
  • 1.03
  • 1.04
  • 1.05
  • 1.07
Fixed in: (no value)



Subject: "use 5.010" is unnecessary
Download (untitled) / with headers
text/plain 181b
The DBD-XBase testsuite runs fine with perl 5.8.9 if both existing "use 5.010" statements are removed. So I assume that the version restriction can be removed. Regards, Slaven
Download (untitled) / with headers
text/plain 366b
The use 5.010 is a statement that I really don't have the capacity to take older perl versions into account anymore when developing and maintaining the module. Distributions packaging the module which have older perl versions are of course welcome to change/remove it in packaging time. But I as upstream would prefer to be able to set the minimal expected version.
Download (untitled) / with headers
text/plain 684b
On 2013-09-21 21:12:15, JANPAZ wrote: Show quoted text
> The use 5.010 is a statement that I really don't have the capacity to > take older perl versions into account anymore when developing and > maintaining the module. > > Distributions packaging the module which have older perl versions are > of course welcome to change/remove it in packaging time. But I as > upstream would prefer to be able to set the minimal expected version.
There's CPAN Testers, there's travis-ci, so you don't have to test old Perl versions yourself. Just create a trial/development version of the distro, upload to CPAN, wait some days, and see if things are working for all OS and Perl versions. Regards, Slaven
Download (untitled) / with headers
text/plain 759b
On 2013-12-10 17:59:39, SREZIC wrote: Show quoted text
> On 2013-09-21 21:12:15, JANPAZ wrote:
> > The use 5.010 is a statement that I really don't have the capacity to > > take older perl versions into account anymore when developing and > > maintaining the module. > > > > Distributions packaging the module which have older perl versions are > > of course welcome to change/remove it in packaging time. But I as > > upstream would prefer to be able to set the minimal expected version.
> > > There's CPAN Testers, there's travis-ci, so you don't have to test old > Perl versions yourself. Just create a trial/development version of the > distro, upload to CPAN, wait some days, and see if things are working > for all OS and Perl versions.
Do you want to give it a try?
Download (untitled) / with headers
text/plain 228b
On Tue Jun 03 03:11:24 2014, SREZIC wrote: Show quoted text
> > Do you want to give it a try?
No, not really. I don't see the benefit of encouraging 5.8 in 2014. Do you have a specific use case when not supporting 5.8 breaks your deployments?
Download (untitled) / with headers
text/plain 1.4k
On 2014-06-03 05:10:50, JANPAZ wrote: Show quoted text
> On Tue Jun 03 03:11:24 2014, SREZIC wrote:
> > > > Do you want to give it a try?
> > No, not really. I don't see the benefit of encouraging 5.8 in 2014.
There's still perl 5.8 around in the world. RHEL5 ships perl 5.8.8, and is supported until 2017 (the extended life phase, whatever this means, even lasts until 2020). A central university server I every now and then still login with Solaris 10 running has only 5.8.4 installed. I can imagine many other situations where older perls are installed. Show quoted text
> Do you have a specific use case when not supporting 5.8 breaks your > deployments?
My specific case is in https://github.com/eserte/bbbike/blob/master/.travis.yml I would like to get rid of the special handling for DBD::XBase, given that it's unnecessary (the newest DBD::XBase version works with 5.8.x). I find your attitude too pessimistic, and it's only focussed at one edge where things can break: a too old perl version. But what about too new perl versions? Why don't you put a 'die "Too new perl version" if $] > 5.014' in your Makefile.PL? And I bet you don't have the ability to test on all operating systems, so why don't you put a 'die "Not supported OS" if $^O eq "linux"'? Still the easiest solution is to remove the restriction, and if you find out that things are not working anymore with older perls, then herewith I offer you help. Regards, Slaven Regards, Slaven
Download (untitled) / with headers
text/plain 1003b
On Thu Jun 05 02:31:59 2014, SREZIC wrote: Show quoted text
> > There's still perl 5.8 around in the world. RHEL5 ships perl 5.8.8, > and is supported until 2017 (the extended life phase, whatever this > means, even lasts until 2020). A central university
And I maintain perl-DBD-XBase in EPEL 5 and there's perl-DBD-XBase-0.241-5.el5.noarch.rpm there. Show quoted text
> and then still login with Solaris 10 running has only 5.8.4 installed.
If perl came as package from Sun/Oracle, you probably should ask them to package DBD::XBase as native Solaris package as well. Show quoted text
> > Do you have a specific use case when not supporting 5.8 breaks your > > deployments?
> > My specific case is in > https://github.com/eserte/bbbike/blob/master/.travis.yml > I would like to get rid of the special handling for DBD::XBase, given > that it's unnecessary (the newest DBD::XBase version works with > 5.8.x).
Isn't the cleanest solution getting DBD::XBase packaged properly as .deb package so that it can be installed via apt-get, not via cpanm?
On 2014-06-06 04:34:16, JANPAZ wrote: Show quoted text
> On Thu Jun 05 02:31:59 2014, SREZIC wrote:
> > > > There's still perl 5.8 around in the world. RHEL5 ships perl 5.8.8, > > and is supported until 2017 (the extended life phase, whatever this > > means, even lasts until 2020). A central university
> > And I maintain perl-DBD-XBase in EPEL 5 and there's perl-DBD-XBase- > 0.241-5.el5.noarch.rpm there.
What if the users need the newest DBD-XBase? Show quoted text
> > and then still login with Solaris 10 running has only 5.8.4 > > installed.
> > If perl came as package from Sun/Oracle, you probably should ask them > to package DBD::XBase as native Solaris package as well.
How likely is the success of such an attempt? I am just an unprivileged user on this system. I don't know anything about Solaris packages, the policy about requesting one at Oracle, and I would have to ask the sysadmin to install it... It's much more easier to install perl packages via CPAN.pm and setup a local::lib-like system. Anyway, even if somebody would build such a package for Solaris: he would have to patch the "use 5.010" away. Show quoted text
> > > Do you have a specific use case when not supporting 5.8 breaks your > > > deployments?
> > > > My specific case is in > > https://github.com/eserte/bbbike/blob/master/.travis.yml > > I would like to get rid of the special handling for DBD::XBase, given > > that it's unnecessary (the newest DBD::XBase version works with > > 5.8.x).
> > Isn't the cleanest solution getting DBD::XBase packaged properly as > .deb package so that it can be installed via apt-get, not via cpanm?
No, that's not how travis-ci works. Normally you don't specify any CPAN packages; everything is resolved and installed automatically by travis-ci, using normal perl/CPAN mechanisms (PREREQ_PM in Makefile.PL etc.). The list of CPAN modules explicitly listed in the .travis.yml is just for the exceptions. In an ideal world even the apt-get statements shouldn't be there but be replaced by Alien-* distributions. Anyway, all these complications wouldn't be necessary if just the "use 5.010" was removed...


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.