# from Ricardo SIGNES
# on Wednesday 01 October 2008:
>* Ken Williams <[EMAIL PROTECTED]> [2008-10-01T12:15:04]
>
>> On Wed, Oct 1, 2008 at 11:12 AM, Smylers <[EMAIL PROTECTED]> wrote:
>> > But what if the bundled version of latest.pm is buggy and I
>> > already have a later latest.pm installed on my system? That will
>> > use the wrong one!!
>>
>> latest.pm doesn't ever get installed on anyone's computer. If you
>> install it, we have a backup plan for that too - the guys in black
>> coats will come and take your computer away.
>
>Well, at this point we're back to "everybody must upgrade everything."
>Presumably latest.pm knows to use the installed latest.pm if it's
> later, even if this is rarely true and even more rarely needed.
There is no 'installed latest.pm', and yes this is a potential for bugs
with any bundling solution. Even if there were an 'installed
latest.pm', what if the bundled latest.pm had a bug where it failed to
give way to the installed one?
We could recommend that the Build.PL does BEGIN {push(@INC, 'inc')}
instead of use lib 'inc' (an unshift()), which gives the target the
opportunity to upgrade (or break) their latest.pm.
But what we're talking about is allowing the target machine to escape
from a bad situation caused by hard-coded/bundled code -- and that can
be solved with a simple unshift(@INC, sub {...}) or various other
hackery where you would say perl -MDevel::noinc Build.PL or whatever.
But latest.pm is fairly short and simple, which reduces the bug rate.
It could probably still use some testing -- given that I just fixed a
non-starter bug in it the other day, I appear to be the only user.
--Eric
--
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
--Donald Knuth
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
