Re: RC2 and perl modules

[Chris Travers <..hidden..>]

On Fri, Sep 23, 2011 at 9:18 AM, Pete Houston <..hidden..> wrote:
> On Fri, Sep 23, 2011 at 08:54:44AM -0700, Chris Travers wrote:
>> > The problem I had was when I had installed RC2 on a stock
>> > Centos 6 installation (which has perl 5.10.1) it did not have
>> > Time::HiRes originally installed, so the module had to be added later
>> > via yum. Erik's point is that the module is listed as a core module at
>> > http://perldoc.perl.org/index-modules-T.html which is true, but the way
>> > RHEL/CentOS is packaged, not all of the core modules are installed with
>> > the base perl package.
>>
>> Ouch.  Is this specific to RHEL/CentOS/SL 6?  Was it the case with 5 as well?
>
> It seems to be specific to version 6. In v5 the main perl rpm includes
> Time::HiRes and this is also true in (at least some versions of) Fedora.
>
>> The only issue here (and why I backed Erik's initial decision on this)
>> was that we don't necessarily want to flood the requirements list with
>> a set of dependencies which are packaged with core Perl.  If Red Hat
>> is doing something crazy with packaging Perl, this is a problem for
>> Red Hat users, not for all users.  Consequently it makes more sense to
>> put in a note saying "If you are running x, perl doesn't come with y
>> so you have to install it separately" rather than just saying "you
>> need y."
>
> That's a good point and I think a sensible way of presenting it to the
> user.
>
>> I'm also in process of reviewing whether this might be a stale
>> dependency.  I will let you know.
>
> Well, that would be ideal as then the whole issue disappears. :-)
>
> FWIW, the only thing it seems to be used for in LedgerSMB/Auth/DB.pm is
> in session_create () where gettimeofday () is used to generate a
> pseudorandom transaction ID from the microseconds field. I could find no
> reference to it in any other file either.
>
That's about where I am in my review.  I will be picking this up in my
review tomorrow.

My suspicion is that this was used for checking for repeat HTTP
requests that would come in concurrently (i.e. clicking a button twice
instead of once) and that our way of addressing this in 1.3 is
different enough that this is not needed.  But I need to verify that
and put it through some testing before removing the code.

Best Wishes,
Chris Travers