Skip Menu |

This queue is for tickets about the CPAN CPAN distribution.

Report information
The Basics
Id: 17699
Status: resolved
Priority: 0/
Queue: CPAN
People
Owner: Nobody in particular
Requestors: adamk [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Fri Feb 17 10:40:36 2006 adamk [...] cpan.org - Ticket created
Subject: Win32 CamelPack 5.6 fails to update to 1.84
Installed CamelPack 5.6 on Win32, tried to install Bundle::CPAN, got the following. Checksum for \.cpan\sources\authors\id\A\AN\ANDK\CPAN-1.84.tar.gz ok Scanning cache \.cpan\build\. for sizes CPAN: Archive::Tar loaded ok CPAN-1.84/ CPAN-1.84/t/ CPAN-1.84/t/30shell.t CPAN-1.84/t/50pod.t CPAN-1.84/t/CPAN/ CPAN-1.84/t/CPAN/modules/ CPAN-1.84/t/CPAN/modules/02packages.details.txt CPAN-1.84/t/CPAN/modules/03modlist.data CPAN-1.84/t/CPAN/authors/ CPAN-1.84/t/CPAN/authors/id/ CPAN-1.84/t/CPAN/authors/id/A/ CPAN-1.84/t/CPAN/authors/id/A/AN/ CPAN-1.84/t/CPAN/authors/id/A/AN/ANDK/ CPAN-1.84/t/CPAN/authors/id/A/AN/ANDK/CPAN-Test-Dummy-Perl5-Build-Fails-1.01.tar .gz CPAN-1.84/t/CPAN/authors/id/A/AN/ANDK/CPAN-Test-Dummy-Perl5-Make-1.01.tar.gz CPAN-1.84/t/CPAN/authors/id/A/AN/ANDK/CPAN-Test-Dummy-Perl5-Make-Zip-1.01.zip CPAN-1.84/t/CPAN/authors/id/A/AN/ANDK/CPAN-Test-Dummy-Perl5-BuildOrMake-1.01.tar .gz CPAN-1.84/t/CPAN/authors/id/A/AN/ANDK/CPAN-Test-Dummy-Perl5-Make-Failearly-1.01. tar.gz CPAN-1.84/t/CPAN/authors/id/A/AN/ANDK/CPAN-Test-Dummy-Perl5-Build-1.01.tar.gz CPAN-1.84/t/CPAN/authors/id/A/AN/ANDK/CHECKSUMS CPAN-1.84/t/CPAN/authors/id/A/AN/CHECKSUMS CPAN-1.84/t/CPAN/authors/id/A/CHECKSUMS CPAN-1.84/t/CPAN/authors/id/CHECKSUMS CPAN-1.84/t/CPAN/authors/01mailrc.txt CPAN-1.84/t/CPAN/TestConfig.pm CPAN-1.84/t/02nox.t CPAN-1.84/t/01loadme.t CPAN-1.84/t/dot-cpan/ CPAN-1.84/t/dot-cpan/Bundle/ CPAN-1.84/t/dot-cpan/Bundle/CpanTestDummies.pm CPAN-1.84/t/10version.t CPAN-1.84/t/03pkgs.t CPAN-1.84/t/00signature.t CPAN-1.84/t/README.shell.txt CPAN-1.84/t/11mirroredby.t CPAN-1.84/lib/ CPAN-1.84/lib/CPAN.pm CPAN-1.84/lib/Bundle/ CPAN-1.84/lib/Bundle/CPAN.pm CPAN-1.84/lib/CPAN/ CPAN-1.84/lib/CPAN/Debug.pm CPAN-1.84/lib/CPAN/FirstTime.pm CPAN-1.84/lib/CPAN/Admin.pm CPAN-1.84/lib/CPAN/Tarzip.pm CPAN-1.84/lib/CPAN/Version.pm CPAN-1.84/lib/CPAN/Nox.pm CPAN-1.84/lib/CPAN/HandleConfig.pm CPAN-1.84/inc/ CPAN-1.84/inc/Test/ CPAN-1.84/inc/Test/Builder.pm CPAN-1.84/inc/Test/More.pm CPAN-1.84/PAUSE2003.pub CPAN-1.84/Changes CPAN-1.84/MANIFEST CPAN-1.84/scripts/ CPAN-1.84/scripts/cpan CPAN-1.84/META.yml CPAN-1.84/ChangeLog CPAN-1.84/Changes.old CPAN-1.84/ChangeLog.old CPAN-1.84/MANIFEST.SKIP CPAN-1.84/PAUSE2005.pub CPAN-1.84/Todo CPAN-1.84/SIGNATURE CPAN-1.84/README CPAN-1.84/Makefile.PL The bundle file "\.cpan\Bundle\CPAN.pm" may be a broken bundlefile. It seems not to contain any bundle definition. Please check the file and if it is bogus, please delete it. Sorry for the inconvenience. The bundle file "\.cpan\Bundle\CPAN.pm" may be a broken bundlefile. It seems not to contain any bundle definition. Please check the file and if it is bogus, please delete it. Sorry for the inconvenience. The bundle file "\.cpan\Bundle\CPAN.pm" may be a broken bundlefile. It seems not to contain any bundle definition. Please check the file and if it is bogus, please delete it. Sorry for the inconvenience. The bundle file "\.cpan\Bundle\CPAN.pm" may be a broken bundlefile. It seems not to contain any bundle definition. Please check the file and if it is bogus, please delete it. Sorry for the inconvenience. Show quoted text
cpan>
  Fri Feb 17 13:31:43 2006 andreas.koenig.gmwojprw [...] franz.ak.mind.de - Correspondence added
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Fri, 17 Feb 2006 19:30:53 +0100
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.gmwojprw [...] franz.ak.mind.de (Andreas J. Koenig)
Show quoted text
>>>>> On Fri, 17 Feb 2006 10:40:37 -0500 (EST), " via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
> The bundle file "\.cpan\Bundle\CPAN.pm" may be a broken > bundlefile. It seems not to contain any bundle definition. > Please check the file and if it is bogus, please delete it. > Sorry for the inconvenience.
I've heard this before and I believe it is a bug in CPAN 1.76 and fixed in 1.84. If you install CPAN 1.84 first and activate it and then install Bundle::Cpan, then it should work. Of course you must follow the advice to remove the bogus bundle file first. -- andreas
  Fri Feb 17 13:31:45 2006 The RT System itself - Status changed from 'new' to 'open'
  Fri Feb 17 13:40:55 2006 andreas.koenig.gmwojprw [...] franz.ak.mind.de - Correspondence added
CC: undisclosed-recipients:;
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Fri, 17 Feb 2006 19:30:31 +0100
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.gmwojprw [...] franz.ak.mind.de (Andreas J. Koenig)
Show quoted text
>>>>> On Fri, 17 Feb 2006 10:40:37 -0500 (EST), " via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
> The bundle file "\.cpan\Bundle\CPAN.pm" may be a broken > bundlefile. It seems not to contain any bundle definition. > Please check the file and if it is bogus, please delete it. > Sorry for the inconvenience.
I've heard this before and I believe it is a bug in CPAN 1.76 and fixed in 1.84. If you install CPAN 1.84 first and activate it and then install Bundle::Cpan, then it should work. Of course you must follow the advice to remove the bogus bundle file first. -- andreas
  Fri Feb 17 13:40:57 2006 andreas.koenig.gmwojprw [...] franz.ak.mind.de - Correspondence added
CC: undisclosed-recipients:;
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Fri, 17 Feb 2006 19:30:45 +0100
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.gmwojprw [...] franz.ak.mind.de (Andreas J. Koenig)
Show quoted text
>>>>> On Fri, 17 Feb 2006 10:40:37 -0500 (EST), " via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
> The bundle file "\.cpan\Bundle\CPAN.pm" may be a broken > bundlefile. It seems not to contain any bundle definition. > Please check the file and if it is bogus, please delete it. > Sorry for the inconvenience.
I've heard this before and I believe it is a bug in CPAN 1.76 and fixed in 1.84. If you install CPAN 1.84 first and activate it and then install Bundle::Cpan, then it should work. Of course you must follow the advice to remove the bogus bundle file first. -- andreas
  Fri Feb 17 15:19:33 2006 adam [...] phase-n.com - Correspondence added
CC: ADAMK [...] cpan.org
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sat, 18 Feb 2006 07:18:39 +1100
To: bug-CPAN [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
OK, I found the time to trace this. Looking at the Bundle file itself... it would appear it's not the bundle file at all. It's actually CPAN.pm itself that ends up at Bundle/CPAN.pm. I've got no idea why this might be. Adam K andreas.koenig.gmwojprw@franz.ak.mind.de via RT wrote: Show quoted text
>>>>>>On Fri, 17 Feb 2006 10:40:37 -0500 (EST), " via RT" <bug-CPAN@rt.cpan.org> said:
> >
> > The bundle file "\.cpan\Bundle\CPAN.pm" may be a broken > > bundlefile. It seems not to contain any bundle definition. > > Please check the file and if it is bogus, please delete it. > > Sorry for the inconvenience.
> > I've heard this before and I believe it is a bug in CPAN 1.76 and > fixed in 1.84. > > If you install CPAN 1.84 first and activate it and then install > Bundle::Cpan, then it should work. Of course you must follow the > advice to remove the bogus bundle file first. >
  Fri Feb 17 15:32:31 2006 adam [...] phase-n.com - Correspondence added
CC: bug-CPAN [...] rt.cpan.org, ADAMK [...] cpan.org
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sat, 18 Feb 2006 07:31:45 +1100
To: Adam Kennedy <adam [...] phase-n.com>
From: Adam Kennedy <adam [...] phase-n.com>
Actually, I tell a lie! I nailed the bugger down. CPAN::Bundle::find_bundle_file iterates through looking for BOTH Bundle/CPAN.pm and then if it can't find that, just plain CPAN.pm. Except instead of going all the way to the bottom of the MANIFEST and then starting again, it does BOTH searches in parallel. SO, it means if CPAN.pm is higher up in the MANIFEST that Bundle/CPAN.pm, it gets found by mistake, and the wrong file gets copied to the Bundle location. So, two part solution. Firstly, in find_bundle_file, if you haven't already make it re-read the MANIFEST and start from the top again. And second, when you package up CPAN.pm, as a special case so you can work with older Perls, you need to ensure that Bundle/CPAN.pm is ALWAYS listed higher in the MANIFEST than CPAN.pm itself. Once a 1.85 is uploaded with the both of those, it will get rid of all past, present and future errors of this type. A 100% solution! :) Adam K Adam Kennedy wrote: Show quoted text
> OK, I found the time to trace this. > > Looking at the Bundle file itself... it would appear it's not the bundle > file at all. > > It's actually CPAN.pm itself that ends up at Bundle/CPAN.pm. > > I've got no idea why this might be. > > Adam K > > andreas.koenig.gmwojprw@franz.ak.mind.de via RT wrote: >
>>>>>>> On Fri, 17 Feb 2006 10:40:37 -0500 (EST), " via RT" >>>>>>> <bug-CPAN@rt.cpan.org> said:
>> >> >>
>> > The bundle file "\.cpan\Bundle\CPAN.pm" may be a broken >> > bundlefile. It seems not to contain any bundle definition. >> > Please check the file and if it is bogus, please delete it. >> > Sorry for the inconvenience.
>> >> I've heard this before and I believe it is a bug in CPAN 1.76 and >> fixed in 1.84. >> >> If you install CPAN 1.84 first and activate it and then install >> Bundle::Cpan, then it should work. Of course you must follow the >> advice to remove the bogus bundle file first. >>
  Sat Feb 18 03:41:13 2006 andreas.koenig.gmwojprw [...] franz.ak.mind.de - Correspondence added
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sat, 18 Feb 2006 09:40:19 +0100
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.gmwojprw [...] franz.ak.mind.de (Andreas J. Koenig)
Show quoted text
>>>>> On Fri, 17 Feb 2006 15:32:32 -0500 (EST), "adam@phase-n.com via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=17699 >
Show quoted text
> Actually, I tell a lie!
Show quoted text
> I nailed the bugger down.
Hmmm. Show quoted text
> CPAN::Bundle::find_bundle_file iterates through looking for BOTH > Bundle/CPAN.pm and then if it can't find that, just plain CPAN.pm.
I knew that, I didn't tell you though:-( Show quoted text
> Except instead of going all the way to the bottom of the MANIFEST and > then starting again, it does BOTH searches in parallel.
Show quoted text
> SO, it means if CPAN.pm is higher up in the MANIFEST that > Bundle/CPAN.pm, it gets found by mistake, and the wrong file gets copied > to the Bundle location.
Nope, I don't believe this is happening. Show quoted text
> So, two part solution.
Show quoted text
> Firstly, in find_bundle_file, if you haven't already make it re-read the > MANIFEST and start from the top again.
I don't believe that either. See, there is a "last" as soon as Bundle/CPAN.pm is found, there is no "last" after just CPAN.pm is found. Show quoted text
> And second, when you package up CPAN.pm, as a special case so you can > work with older Perls, you need to ensure that Bundle/CPAN.pm is ALWAYS > listed higher in the MANIFEST than CPAN.pm itself.
Nope, this won't help. I still believ that my explanation is correct. The wrong bundle file was either found by an older version of CPAN.pm, maybe months before, or by other, unknown mechanics. Show quoted text
> Once a 1.85 is uploaded with the both of those, it will get rid of all > past, present and future errors of this type.
Show quoted text
> A 100% solution! :)
If I could believe you, I'd do that, but think for a moment: if your analysis were right, the bug would show up on Unix too. -- andreas
  Sat Feb 18 04:24:07 2006 adam [...] phase-n.com - Correspondence added
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sat, 18 Feb 2006 20:09:48 +1100
To: bug-CPAN [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
andreas.koenig.gmwojprw@franz.ak.mind.de via RT wrote: Show quoted text
>>>>>> On Fri, 17 Feb 2006 15:32:32 -0500 (EST), "adam@phase-n.com via RT" <bug-CPAN@rt.cpan.org> said:
>
> > <URL: http://rt.cpan.org/Ticket/Display.html?id=17699 >
>
> > Actually, I tell a lie!
>
> > I nailed the bugger down.
> > Hmmm. >
> > CPAN::Bundle::find_bundle_file iterates through looking for BOTH > > Bundle/CPAN.pm and then if it can't find that, just plain CPAN.pm.
> > I knew that, I didn't tell you though:-( >
> > Except instead of going all the way to the bottom of the MANIFEST and > > then starting again, it does BOTH searches in parallel.
>
> > SO, it means if CPAN.pm is higher up in the MANIFEST that > > Bundle/CPAN.pm, it gets found by mistake, and the wrong file gets copied > > to the Bundle location.
> > Nope, I don't believe this is happening. >
> > So, two part solution.
>
> > Firstly, in find_bundle_file, if you haven't already make it re-read the > > MANIFEST and start from the top again.
> > I don't believe that either. See, there is a "last" as soon as > Bundle/CPAN.pm is found, there is no "last" after just CPAN.pm is > found. >
> > And second, when you package up CPAN.pm, as a special case so you can > > work with older Perls, you need to ensure that Bundle/CPAN.pm is ALWAYS > > listed higher in the MANIFEST than CPAN.pm itself.
> > Nope, this won't help. I still believ that my explanation is correct. > The wrong bundle file was either found by an older version of CPAN.pm, > maybe months before, or by other, unknown mechanics.
Well, I removed the old bundle file and it keeps being reselected. It this clears things up for you, the Bundle file as extracted from the 1.84 tarball by CPAN.pm 1.76 and placed in the bundle directory is 245k in size. If I remove the "months before" file and rerun, it keeps copying the 245k file back in. And I can replicate it reliably. Show quoted text
> > Once a 1.85 is uploaded with the both of those, it will get rid of all > > past, present and future errors of this type.
>
> > A 100% solution! :)
> > If I could believe you, I'd do that, but think for a moment: if your > analysis were right, the bug would show up on Unix too.
hmm.... very very good point. I shall investigate a little further. So to summarise I'm certain CPAN.pm is being considered to be the bundle file instead of Bundle/CPAN.pm, and I'm certain that the bug is lexically withing CPAN::Bundle::find_bundle_file somewhere, but I'm probably NOT correct on the specific reason within that function. Which I'll take a look at now, and see if I can explain the platform issue as well. Out of curiosity though, is there a specific reason that the Bundle::CPAN module has to be inside the main CPAN tarball? I suspect that even if my specific diagnosis is wrong at a line level, moving it out into it's own dist would fix the problem. But don't do that. I'll go work out the why-not-on-Unix problem first. Adam K
  Sat Feb 18 06:06:01 2006 andreas.koenig.gmwojprw [...] franz.ak.mind.de - Correspondence added
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sat, 18 Feb 2006 12:05:12 +0100
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.gmwojprw [...] franz.ak.mind.de (Andreas J. Koenig)
Show quoted text
>>>>> On Sat, 18 Feb 2006 04:24:12 -0500 (EST), "adam@phase-n.com via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
> Well, I removed the old bundle file and it keeps being reselected.
Show quoted text
> It this clears things up for you, the Bundle file as extracted from the > 1.84 tarball by CPAN.pm 1.76 and placed in the bundle directory is 245k > in size.
Show quoted text
> If I remove the "months before" file and rerun, it keeps copying the > 245k file back in. And I can replicate it reliably.
Copy 1.84 over 1.76 and retry. This is the lithmus test or however they call it. I believe I have fixed this, I just cannot remember when and how. -- andreas
  Sat Feb 18 06:13:59 2006 adam [...] phase-n.com - Correspondence added
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sat, 18 Feb 2006 22:11:05 +1100
To: bug-CPAN [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
andreas.koenig.gmwojprw@franz.ak.mind.de via RT wrote: Show quoted text
>>>>>> On Sat, 18 Feb 2006 04:24:12 -0500 (EST), "adam@phase-n.com via RT" <bug-CPAN@rt.cpan.org> said:
>
> > Well, I removed the old bundle file and it keeps being reselected.
>
> > It this clears things up for you, the Bundle file as extracted from the > > 1.84 tarball by CPAN.pm 1.76 and placed in the bundle directory is 245k > > in size.
>
> > If I remove the "months before" file and rerun, it keeps copying the > > 245k file back in. And I can replicate it reliably.
> > Copy 1.84 over 1.76 and retry. This is the lithmus test or however they > call it. > > I believe I have fixed this, I just cannot remember when and how.
Well, as I said it's a two part problem. If all the 1.76 installation out there on (whatever I've done to trigger this) can't upgrade to 1.84, and there's something we can do to the new CPAN.pm dist that can workaround the problem in 1.76, I'd love to be able to fix that as well as fixing the original bug. Adam K
  Sat Feb 18 06:48:53 2006 andreas.koenig.gmwojprw [...] franz.ak.mind.de - Correspondence added
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sat, 18 Feb 2006 12:48:00 +0100
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.gmwojprw [...] franz.ak.mind.de (Andreas J. Koenig)
Show quoted text
>>>>> On Sat, 18 Feb 2006 06:14:00 -0500 (EST), "adam@phase-n.com via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
>> Copy 1.84 over 1.76 and retry. This is the lithmus test or however they >> call it. >> >> I believe I have fixed this, I just cannot remember when and how.
Show quoted text
> Well, as I said it's a two part problem.
Show quoted text
> If all the 1.76 installation out there on (whatever I've done to trigger > this) can't upgrade to 1.84, and there's something we can do to the new > CPAN.pm dist that can workaround the problem in 1.76, I'd love to be > able to fix that as well as fixing the original bug.
I'm with you on that and it seems to me that putting Bundle::CPAN in a separate distro would solve this part of the problem for now. Users can upgrade immediately if they say 'install CPAN' instead of 'install Bundle::CPAN'. Am I right on this? If you try to copy 1.84 over 1.76 and can then install Bundle::CPAN, that would show that the original bug is fixed and we need only invent workarounds for the userbase with 1.76. -- andreas
  Sat Feb 18 06:55:00 2006 adam [...] phase-n.com - Correspondence added
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sat, 18 Feb 2006 22:52:01 +1100
To: bug-CPAN [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
andreas.koenig.gmwojprw@franz.ak.mind.de via RT wrote: Show quoted text
>>>>>> On Sat, 18 Feb 2006 06:14:00 -0500 (EST), "adam@phase-n.com via RT" <bug-CPAN@rt.cpan.org> said:
>
> >> Copy 1.84 over 1.76 and retry. This is the lithmus test or however they > >> call it. > >> > >> I believe I have fixed this, I just cannot remember when and how.
>
> > Well, as I said it's a two part problem.
>
> > If all the 1.76 installation out there on (whatever I've done to trigger > > this) can't upgrade to 1.84, and there's something we can do to the new > > CPAN.pm dist that can workaround the problem in 1.76, I'd love to be > > able to fix that as well as fixing the original bug.
> > I'm with you on that and it seems to me that putting Bundle::CPAN in a > separate distro would solve this part of the problem for now. > > Users can upgrade immediately if they say 'install CPAN' instead of > 'install Bundle::CPAN'. Am I right on this? > > If you try to copy 1.84 over 1.76 and can then install Bundle::CPAN, > that would show that the original bug is fixed and we need only invent > workarounds for the userbase with 1.76.
That should be correct. I'm going to complete the original diagnosis (just so I can at least confirm what caused the problem, since I don't like fixing problems without knowing what caused them) and then I'll do the 1.04 upgrade and retest there. But yes, splitting out Bundle::CPAN is probably a good idea and I'm confident it should fix the problem for 1.76. And yes, you would do seperate 'install CPAN' and 'install Bundle::CPAN' commands. They would both work. Adam K
  Sat Feb 18 08:21:20 2006 adam [...] phase-n.com - Correspondence added
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sun, 19 Feb 2006 00:18:23 +1100
To: bug-CPAN [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
Show quoted text
> I don't believe that either. See, there is a "last" as soon as > Bundle/CPAN.pm is found, there is no "last" after just CPAN.pm is > found. >
> > And second, when you package up CPAN.pm, as a special case so you can > > work with older Perls, you need to ensure that Bundle/CPAN.pm is ALWAYS > > listed higher in the MANIFEST than CPAN.pm itself.
> > Nope, this won't help. I still believ that my explanation is correct. > The wrong bundle file was either found by an older version of CPAN.pm, > maybe months before, or by other, unknown mechanics. >
> > Once a 1.85 is uploaded with the both of those, it will get rid of all > > past, present and future errors of this type.
>
> > A 100% solution! :)
> > If I could believe you, I'd do that, but think for a moment: if your > analysis were right, the bug would show up on Unix too.
OK, here we go. As you scan though the manifest file, the contents is in Unix format. ----------------------- ... inc/Test/More.pm lib/Bundle/CPAN.pm lib/CPAN.pm lib/CPAN/Admin.pm ... ----------------------- It's looking for two values $what = 'Bundle\\CPAN.pm'; $what2 = 'CPAN.pm'; Although it does a check for MacOS and does a map from : to / it doesn't do the same for Windows. This is the actual iteration code ----------------------- while (<$fh>) { next if /^\s*\#/; my($file) = /(\S+)/; if ($file =~ m|\Q$what\E$|) { $bu = $file; # return File::Spec->catfile($where,$bu); # bad last; } # retry if she managed to # have no Bundle directory $bu = $file if $file =~ m|\Q$what2\E$|; } ---------------------- When it hits the lib/Bundle/CPAN.pm line, it fails to match Bundle\\CPAN.pm but DOES set the $bu ("backup"?) value. But then on the next line below the $bu matches AGAIN, and is overwritten with the main CPAN.pm library. When it gets to the end, what is left in $bu is the main CPAN.pm library, not the bundle. So, solutions. 1. To handle the current codebase (which I'll try in a sec...) Rather than special casing MacOS in there, the $what value passed in needs to be either unix-specific, or the name of the class (which you can convert to unix-specific). Then after you get a match, again rather than special-casing MacOS you can split on / and File::Spec->catfile to get the platform version. I don't know what you are doing now, so this advice could be redundant, but I'll check that after this. 2. To handle the legacy cases a) Splitting out Bundle::CPAN into a seperate distribution will certainly work once you release CPAN.pm 1.85 and everything reindexes. b) Alternatively, you can do the opposite of my previous advice. If you make sure that lib/Bundle/CPAN.pm is the LAST element in the list (or at least after any other CPAN.pm files) then even though other files might temporarily be in $bu, it will be the correct file that gets set in there at the end of the search. I'll move on to testing 1.84 now. Adam K
  Sat Feb 18 08:54:28 2006 adam [...] phase-n.com - Correspondence added
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sun, 19 Feb 2006 00:51:35 +1100
To: bug-CPAN [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
andreas.koenig.gmwojprw@franz.ak.mind.de via RT wrote: Show quoted text
>>>>>> On Sat, 18 Feb 2006 06:14:00 -0500 (EST), "adam@phase-n.com via RT" <bug-CPAN@rt.cpan.org> said:
>
> >> Copy 1.84 over 1.76 and retry. This is the lithmus test or however they > >> call it. > >> > >> I believe I have fixed this, I just cannot remember when and how.
>
> > Well, as I said it's a two part problem.
>
> > If all the 1.76 installation out there on (whatever I've done to trigger > > this) can't upgrade to 1.84, and there's something we can do to the new > > CPAN.pm dist that can workaround the problem in 1.76, I'd love to be > > able to fix that as well as fixing the original bug.
> > I'm with you on that and it seems to me that putting Bundle::CPAN in a > separate distro would solve this part of the problem for now. > > Users can upgrade immediately if they say 'install CPAN' instead of > 'install Bundle::CPAN'. Am I right on this? > > If you try to copy 1.84 over 1.76 and can then install Bundle::CPAN, > that would show that the original bug is fixed and we need only invent > workarounds for the userbase with 1.76.
Without being able to try it yet (due to the makefile problem) I've had a look at the code in 1.84 and it looks like the same problem will happen. So what we probably need to do is at about line 5997, change - $from = $self->find_bundle_file($dist->{'build_dir'},$me); + $from = $self->find_bundle_file($dist->{'build_dir'},join('/',@me)); That way what goes through to ->find_bundle_file is always in Unix format. Then in the find_bundle_file function itself you pull out the initial max stuff, since it is no longer needed. my $what2 = $what; - if ($^O eq 'MacOS') { - $what =~ s/^://; - $what =~ tr|:|/|; - $what2 =~ s/:Bundle://; - $what2 =~ tr|:|/|; - } else { - $what2 =~ s|Bundle[/\\]||; - } + $what2 =~ s|Bundle[/\\]||; And then after the iteration, change - $bu =~ tr|/|:| if $^O eq 'MacOS'; - return File::Spec->catfile($where, $bu) if $bu; + return File::Spec->catfile($where, split /\//, $bu) if $bu; And it should work across fully platform neutrally. Of course, all this assumed that CPAN::Bundle::find_bundle_file is NOT a public method and we can change the way it works to take a unix-only path like that. If it IS a public method, then we need an approach that will File::Spec split the path and join it back to get the unix one, rather than just the special mac case. The change made to after the iteration will be the same. And hopefully that's the last of the diagnostics I'm going to have to do today :) Adam K
  Sat Feb 18 16:26:01 2006 andreas.koenig.gmwojprw [...] franz.ak.mind.de - Correspondence added
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sat, 18 Feb 2006 22:25:10 +0100
To: bug-CPAN [...] rt.cpan.org
From: andreas.koenig.gmwojprw [...] franz.ak.mind.de (Andreas J. Koenig)
Show quoted text
>>>>> On Sat, 18 Feb 2006 08:54:29 -0500 (EST), "adam@phase-n.com via RT" <bug-CPAN@rt.cpan.org> said:
Show quoted text
> And hopefully that's the last of the diagnostics I'm going to have to do > today :)
You did an Overwelming Job on this one. In German we say "Hut ab" and a free translation would just be "Hat off". Whatever. I'll release tomorrow some 1.85 distros. Thanks! -- andreas
  Sat Feb 18 16:42:26 2006 adam [...] phase-n.com - Correspondence added
Subject: Re: [rt.cpan.org #17699] Win32 CamelPack 5.6 fails to update to 1.84
Date: Sun, 19 Feb 2006 08:39:31 +1100
To: bug-CPAN [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
Great, thanks. Then hopefully I can get past 1.84 to dealing with the OTHER problems. Did I mention Term::ReadKey and Module::Build also have big problems :) Adam K andreas.koenig.gmwojprw@franz.ak.mind.de via RT wrote: Show quoted text
>>>>>> On Sat, 18 Feb 2006 08:54:29 -0500 (EST), "adam@phase-n.com via RT" <bug-CPAN@rt.cpan.org> said:
>
> > And hopefully that's the last of the diagnostics I'm going to have to do > > today :)
> > You did an Overwelming Job on this one. In German we say "Hut ab" and > a free translation would just be "Hat off". Whatever. I'll release > tomorrow some 1.85 distros. > > Thanks!
  Sun Feb 19 16:43:42 2006 ANDK [...] cpan.org - Status changed from 'open' to 'resolved'