FAQ
I am trying to clean up the prerequisites for a package that requires
both DBI and DBD::SQLite (UR). CPAN wants to order the prerequisites
in alphabetical order, so it tries to install DBD::SQLite first. It
comes to this part of the DBD::SQLite Makefile.PL code

# Because DBI generates a postamble at configure-time, we need
# the required version of DBI very early.
my $DBI_required = 1.57;
eval {
require DBI;
};
if ( $@ or DBI->VERSION < $DBI_required ) {
print "DBI 1.57 is required to configure this module, please install it or upgrade your CPAN/CPANPLUS shell\n";
exit(0);
}

and fails (although the exit status is zero) because an older version
of DBI is installed. Even though DBI later appears and as PREREQ_PM
in the WriteMakefile call, that line never gets executed, the Makefile
never gets created, and CPAN will go no further with the DBD::SQLite
install. CPAN does continue to try to install other modules,
ultimately failing the requested install because DBD::SQLite is
missing (or too old).

I am not sure what the issue around the DBI postamble is so I am not
sure how to fix this so DBD::SQLite to play nicely with CPAN. Any
ideas/guidance on how to get this to behave as one might expect?

--
David Dooling

Search Discussions

  • Ash Berlin at Jun 19, 2009 at 5:45 pm

    On 19 Jun 2009, at 18:37, David Dooling wrote:

    I am trying to clean up the prerequisites for a package that requires
    both DBI and DBD::SQLite (UR). CPAN wants to order the prerequisites
    in alphabetical order, so it tries to install DBD::SQLite first. It
    comes to this part of the DBD::SQLite Makefile.PL code

    # Because DBI generates a postamble at configure-time, we need
    # the required version of DBI very early.
    my $DBI_required = 1.57;
    eval {
    require DBI;
    };
    if ( $@ or DBI->VERSION < $DBI_required ) {
    print "DBI 1.57 is required to configure this module,
    please install it or upgrade your CPAN/CPANPLUS shell\n";
    exit(0);
    }

    and fails (although the exit status is zero) because an older version
    of DBI is installed. Even though DBI later appears and as PREREQ_PM
    in the WriteMakefile call, that line never gets executed, the Makefile
    never gets created, and CPAN will go no further with the DBD::SQLite
    install. CPAN does continue to try to install other modules,
    ultimately failing the requested install because DBD::SQLite is
    missing (or too old).

    I am not sure what the issue around the DBI postamble is so I am not
    sure how to fix this so DBD::SQLite to play nicely with CPAN. Any
    ideas/guidance on how to get this to behave as one might expect?
    Two possible solutions I can think of:

    1) configure_requires. Doesn't help with old clients
    2) Use the 'Are we running under a CPAN shell' from the (now improved)
    Module::Install::AutoInstall.

    Oh, a bonus 3rd option.

    3) Remove the check and delay it to the first test which does BAIL_OUT
    if DBI is too old.

    -ash
  • Curtis Jewell at Jun 19, 2009 at 6:20 pm

    On Fri, 19 Jun 2009 18:45 +0100, "Ash Berlin" wrote:
    On 19 Jun 2009, at 18:37, David Dooling wrote:

    I am trying to clean up the prerequisites for a package that requires
    both DBI and DBD::SQLite (UR). CPAN wants to order the prerequisites
    in alphabetical order, so it tries to install DBD::SQLite first. It
    comes to this part of the DBD::SQLite Makefile.PL code

    # Because DBI generates a postamble at configure-time, we need
    # the required version of DBI very early.
    my $DBI_required = 1.57;
    eval {
    require DBI;
    };
    if ( $@ or DBI->VERSION < $DBI_required ) {
    print "DBI 1.57 is required to configure this module,
    please install it or upgrade your CPAN/CPANPLUS shell\n";
    exit(0);
    }

    and fails (although the exit status is zero) because an older version
    of DBI is installed. Even though DBI later appears and as PREREQ_PM
    in the WriteMakefile call, that line never gets executed, the Makefile
    never gets created, and CPAN will go no further with the DBD::SQLite
    install. CPAN does continue to try to install other modules,
    ultimately failing the requested install because DBD::SQLite is
    missing (or too old).

    I am not sure what the issue around the DBI postamble is so I am not
    sure how to fix this so DBD::SQLite to play nicely with CPAN. Any
    ideas/guidance on how to get this to behave as one might expect?
    The DBI postamble copies two files from the DBI distribution into the
    DBD driver's distribution - they're the standard framework for any XS
    dbd driver.

    So the postamble is vital.

    I would assume that there was an incompatible change or a necessary bug
    fix in one or the other of these two files in the 1.56 -> 1.57 era that
    would make compilation impossible, although I could be wrong. (It's
    quite possible:
    http://search.cpan.org/diff?fromÛI-1.56&toÛI-1.57#Driver.xst - The
    postamble itself hasn't changed since 1.56, so it's not that.)
    Two possible solutions I can think of:

    1) configure_requires. Doesn't help with old clients
    No, but it's the easiest way to help new ones. It can't hurt.
    2) Use the 'Are we running under a CPAN shell' from the (now improved)
    Module::Install::AutoInstall.
    Do this, too. It will catch what the previous one does not.
    Oh, a bonus 3rd option.

    3) Remove the check and delay it to the first test which does BAIL_OUT
    if DBI is too old.
    Does it even COMPILE if DBI is too old?

    --Curtis
    --
    Curtis Jewell
    swordsman@csjewell.fastmail.us

    %DCL-E-MEM-BAD, bad memory
    -VMS-F-PDGERS, pudding between the ears

    [I use PC-Alpine, which deliberately does not display colors and pictures in HTML mail]
  • David Dooling at Jun 19, 2009 at 6:26 pm

    On Fri, Jun 19, 2009 at 12:20:23PM -0600, Curtis Jewell wrote:
    On Fri, 19 Jun 2009 18:45 +0100, "Ash Berlin" wrote:
    On 19 Jun 2009, at 18:37, David Dooling wrote:
    I am trying to clean up the prerequisites for a package that requires
    both DBI and DBD::SQLite (UR). CPAN wants to order the prerequisites
    in alphabetical order, so it tries to install DBD::SQLite first. It
    comes to this part of the DBD::SQLite Makefile.PL code

    # Because DBI generates a postamble at configure-time, we need
    # the required version of DBI very early.
    my $DBI_required = 1.57;
    eval {
    require DBI;
    };
    if ( $@ or DBI->VERSION < $DBI_required ) {
    print "DBI 1.57 is required to configure this module,
    please install it or upgrade your CPAN/CPANPLUS shell\n";
    exit(0);
    }

    and fails (although the exit status is zero) because an older version
    of DBI is installed. Even though DBI later appears and as PREREQ_PM
    in the WriteMakefile call, that line never gets executed, the Makefile
    never gets created, and CPAN will go no further with the DBD::SQLite
    install. CPAN does continue to try to install other modules,
    ultimately failing the requested install because DBD::SQLite is
    missing (or too old).

    I am not sure what the issue around the DBI postamble is so I am not
    sure how to fix this so DBD::SQLite to play nicely with CPAN. Any
    ideas/guidance on how to get this to behave as one might expect?
    The DBI postamble copies two files from the DBI distribution into the
    DBD driver's distribution - they're the standard framework for any XS
    dbd driver.

    So the postamble is vital.
    But if it were a PREREQ_PM, wouldn't it get installed before
    DBD::SQLite gets built? Or do those files need to be there before
    even the Makefile is created?
    I would assume that there was an incompatible change or a necessary bug
    fix in one or the other of these two files in the 1.56 -> 1.57 era that
    would make compilation impossible, although I could be wrong. (It's
    quite possible:
    http://search.cpan.org/diff?fromÛI-1.56&toÛI-1.57#Driver.xst - The
    postamble itself hasn't changed since 1.56, so it's not that.)
    Two possible solutions I can think of:

    1) configure_requires. Doesn't help with old clients
    No, but it's the easiest way to help new ones. It can't hurt.
    This seems more applicable to DBD::SQLite than something that needs
    DBD::SQLite. Using that would require porting the entire DBD::SQLite
    build system to Module::Install (it currently uses
    ExtUtils::MakeMaker).
    2) Use the 'Are we running under a CPAN shell' from the (now improved)
    Module::Install::AutoInstall.
    Do this, too. It will catch what the previous one does not.
    I'll try this (although I am not entirely sure if it will help; the
    docs are a little light).
    Oh, a bonus 3rd option.

    3) Remove the check and delay it to the first test which does BAIL_OUT
    if DBI is too old.
    Does it even COMPILE if DBI is too old?
    It seems if DBI is a PREREQ_PM, both of these are moot since the
    appropriate version of DBI would be installed before compilation or
    testing.

    --
    David Dooling
  • Curtis Jewell at Jun 19, 2009 at 7:16 pm

    On Fri, 19 Jun 2009 13:26 -0500, "David Dooling" wrote:
    Two possible solutions I can think of:

    1) configure_requires. Doesn't help with old clients
    No, but it's the easiest way to help new ones. It can't hurt.
    This seems more applicable to DBD::SQLite than something that needs
    DBD::SQLite. Using that would require porting the entire DBD::SQLite
    build system to Module::Install (it currently uses
    ExtUtils::MakeMaker).
    Yes, it does, and no, it wouldn't require switching to M::I, because the
    capability is already in there!

    DBD::SQLite's Makefile.PL includes this:

    OPTIONAL( '6.46',
    META_MERGE => {
    configure_requires => {
    'ExtUtils::MakeMaker' => '6.48',
    'File::Spec' => '0.82', # This is not allowed to be computed
    'DBI' => $DBI_required,
    }, ...

    so that if you have a client new enough to pick the configure_requires
    line out of the META.yml, the problem should not arise in the first
    place.
    2) Use the 'Are we running under a CPAN shell' from the (now improved)
    Module::Install::AutoInstall.
    Do this, too. It will catch what the previous one does not.
    I'll try this (although I am not entirely sure if it will help; the
    docs are a little light).
    Oh, a bonus 3rd option.

    3) Remove the check and delay it to the first test which does BAIL_OUT
    if DBI is too old.
    Does it even COMPILE if DBI is too old?
    It seems if DBI is a PREREQ_PM, both of these are moot since the
    appropriate version of DBI would be installed before compilation or
    testing.
    True. The problem being that it requires DBI 1.57 just to build a
    Makefile correctly. (although instead of running an eval {use DBI;
    etc... }, the Makefile.PL should use MM->parse_version to find out the
    version number, I would think...)

    But you're right. By the time it needs to copy the files (during make
    stage), you'd have the right version of DBI in there if you were using a
    CPAN client.

    Why it absolutely insists on the version in the Makefile.PL stage, I
    don't know.

    Personally, I'd make your module do something like this in order to
    brute-force the issue: (heavily psuedocoded)

    # All in core since 5.00504...
    use ExtUtils::MakeMaker; # I think M::I loads it anyway.
    use Config;
    use File::Spec::Functions qw(catfile);

    # Yes, I know this doesn't catch a DBI installed with local::lib or in a
    PREFIX or INSTALL_BASE directory.
    # I don't quite see how to do that easily in EU::MM/M::I style. Maybe
    you do.
    # M::B makes it easy enough - and it's what I use for a lot of things.
    my $dbi_file = do {
    -e catfile($Config{sitelib}, 'DBI.pl') ? catfile($Config{sitelib},
    'DBI.pl')
    : -e catfile($Config{vendorlib}, 'DBI.pl') ?
    catfile($Config{vendorlib}, 'DBI.pl')
    : undef;
    }

    if ((not defined $dbi_file) or (MM->parse_version($dbi_file) < 1.57)) {
    if ($IN_CPAN) {
    # Tell CPAN or CPANPLUS to install DBI, like M::AutoInstall does
    it.Maybe figure out a way to make M::AI do it!
    } else {
    # Tell the user to install DBI
    }
    }

    # process rest of makefile.

    --Curtis
    --
    Curtis Jewell
    swordsman@csjewell.fastmail.us

    %DCL-E-MEM-BAD, bad memory
    -VMS-F-PDGERS, pudding between the ears

    [I use PC-Alpine, which deliberately does not display colors and pictures in HTML mail]
  • David Dooling at Jun 19, 2009 at 9:32 pm

    On Fri, Jun 19, 2009 at 01:16:20PM -0600, Curtis Jewell wrote:
    On Fri, 19 Jun 2009 13:26 -0500, "David Dooling" wrote:
    Two possible solutions I can think of:

    1) configure_requires. Doesn't help with old clients
    No, but it's the easiest way to help new ones. It can't hurt.
    This seems more applicable to DBD::SQLite than something that needs
    DBD::SQLite. Using that would require porting the entire DBD::SQLite
    build system to Module::Install (it currently uses
    ExtUtils::MakeMaker).
    Yes, it does, and no, it wouldn't require switching to M::I, because the
    capability is already in there!

    DBD::SQLite's Makefile.PL includes this:

    OPTIONAL( '6.46',
    META_MERGE => {
    configure_requires => {
    'ExtUtils::MakeMaker' => '6.48',
    'File::Spec' => '0.82', # This is not allowed to be computed
    'DBI' => $DBI_required,
    }, ...

    so that if you have a client new enough to pick the configure_requires
    line out of the META.yml, the problem should not arise in the first
    place.
    That would be great if DBD::SQLite could be made to do the right thing
    here.
  • David Dooling at Jun 19, 2009 at 9:30 pm

    On Fri, Jun 19, 2009 at 01:26:24PM -0500, David Dooling wrote:
    On Fri, Jun 19, 2009 at 12:20:23PM -0600, Curtis Jewell wrote:
    On Fri, 19 Jun 2009 18:45 +0100, "Ash Berlin" wrote:
    On 19 Jun 2009, at 18:37, David Dooling wrote:
    I am trying to clean up the prerequisites for a package that requires
    both DBI and DBD::SQLite (UR). CPAN wants to order the prerequisites
    in alphabetical order, so it tries to install DBD::SQLite first. It
    comes to this part of the DBD::SQLite Makefile.PL code

    # Because DBI generates a postamble at configure-time, we need
    # the required version of DBI very early.
    my $DBI_required = 1.57;
    eval {
    require DBI;
    };
    if ( $@ or DBI->VERSION < $DBI_required ) {
    print "DBI 1.57 is required to configure this module,
    please install it or upgrade your CPAN/CPANPLUS shell\n";
    exit(0);
    }

    and fails (although the exit status is zero) because an older version
    of DBI is installed. Even though DBI later appears and as PREREQ_PM
    in the WriteMakefile call, that line never gets executed, the Makefile
    never gets created, and CPAN will go no further with the DBD::SQLite
    install. CPAN does continue to try to install other modules,
    ultimately failing the requested install because DBD::SQLite is
    missing (or too old).
    2) Use the 'Are we running under a CPAN shell' from the (now improved)
    Module::Install::AutoInstall.
    Do this, too. It will catch what the previous one does not.
    I'll try this (although I am not entirely sure if it will help; the
    docs are a little light).
    This worked. Changing from a series of requires to using -core
    features allows you to specify a dependency order.

    features (
    -core => [
    'DBI' => '1.601',
    'DBD::SQLite' => '1.14',
    ...
    ],
    ...
    );

    Slightly more information can be found here

    http://search.cpan.org/~autrijus/ExtUtils-AutoInstall-0.63/lib/ExtUtils/AutoInstall.pm

    New version has been uploaded.

    https://pause.perl.org/pub/PAUSE/authors/id/S/SA/SAKOHT/
  • Adam Kennedy at Jun 21, 2009 at 5:02 am
    2009/6/20 Ash Berlin <ash_cpan@firemirror.com>
    1) configure_requires. Doesn't help with old clients

    Well, it kind of does.

    There's a phase in the configure_requires plan that occurs after it is
    supported in the core (which is 5.10.1) where we start upgrading various
    distros to bitch in a specific way if they fail.

    So DBD::SQLite could just while "Failed to find DBI, your CPAN client may be
    critically out of date, please upgrade it".

    One the CPAN client is upgraded to ANY version that supports
    configure_requires, the problem goes away forever.

    Only downside remains that the CPAN client out-the-box isn't good enough, so
    we have to make sure to catch this and push the users to upgrade more
    aggressively than they do now.

    Adam K
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/dbd-sqlite/attachments/20090621/05c6a112/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbd-sqlite @
postedJun 19, '09 at 5:37p
activeJun 21, '09 at 5:02a
posts8
users4
websiteshadowcat.co.uk

People

Translate

site design / logo © 2021 Grokbase