not quite sure how this is major.  
Workaround is to set up CPAN -  (perl -MCPAN -e "install ...")

It has also long been assumed that Linux users should be prepared and capable of dealing with setup issues like this.  build-perl-modules.pl is intended as a helper, not a blind automated solution.

I agree.  Chris set it to major, not me.  However, I suspect that someone who has never used CPAN will have no clue what the error message means and how to fix it.

FWIW, the reason I found this is because I was toying with the idea of running build-perl-modules.pl unattended as part of the %post scriptlet in the RPM.  But, that's a different topic and I'm still not sure it's a good idea...

Andy to comment.

This also happens on a fresh Ubuntu Gutsy 7.10 installation. 
I solved it by installing the libmodule-build-perl package.

I haven't tried the new Ubuntu yet but it should work OOTB with our included binary modules.  If you run SC on some system that can't run our modules, you'll need to install Encode::Detect as it is now required.

I would not recommend auto-running build-perl-modules for the RPM.  The vast majoriy of systems can use our included modules unless people have built their own Perl that doesn't support threading for example.

Andy, I agree with your comments but I still think this is a bug.  Specifically, if you run build-perl-modules.pl on a system that has never run CPAN, you will get stuck in an endless loop with an error message that will make no sense to someone unfamiliar with CPAN.  (Actually, I'm not sure why installing libmodule-build-perl package on Ubuntu fixes anything.)  At the very least, I'd suggest either:

- Add a message at the top explaining to the user that if you see this error you need to quit and initialize CPAN
- Disable "$ENV{'PERL_MM_USE_DEFAULT'} = 1;" just for the Encode-Detect build

Can you post the output of what happens?

Created attachment 2307 [details]
Log of the failure

See attachment.  The last message repeats until interrupted with ctrl-C.

OK yeah that's bad.  What happens if you disable $ENV{'PERL_MM_USE_DEFAULT'}?  I assume you'll get the 'Install Module::Build now from CPAN?' prompt, but then what happens?

It hangs at:

Downloading Encode-Detect-1.00.tar.gz to: /var/cache/squeezecenter
Can't locate auto/Compress/Zlib/autosplit.ix in @INC (@INC contains: /usr/local/slimserver/CPAN /usr/share/squeezecenter/CPAN CPAN /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .) at /usr/lib/perl5/5.8.8/AutoLoader.pm line 160, <STDIN> line 3.
 at /usr/share/squeezecenter/CPAN/Compress/Zlib.pm line 15
Uncompressing..
Configuring..
 /usr/bin/perl Makefile.PL 

Weird.  Not what I expected...

I've installed the CPAN modules by hand.  However, the build-perl-modules.pl file grabs the modules from the slimdevices trunk line.  This appears to be where the problem is.  The Encode-Detect module can be compiled manually through CPAN.

(In reply to comment #12)
> I've installed the CPAN modules by hand.  However, the build-perl-modules.pl
> file grabs the modules from the slimdevices trunk line.  This appears to be
> where the problem is.  The Encode-Detect module can be compiled manually
> through CPAN.
> 

Forgot to mention I'm using Freelink on a Linkstation, PPC processor.

This is also happening on Gentoo (I'm currently trying to create a Portage ebuild (aka package) for SqueezeCenter 7). I've raised this in bug 6389 but have been pointed to this as a duplicate.

The problem was the same for me - those messages repeating in a loop because CPAN was not set up. In a Gentoo ebuild (which effectively compiles the package from source) CPAN can't be relied upon to be set up for the user and there is no specific arch tarball available because the same ebuild has to run on a number of architectures (x86/arm/mips etc etc).

I think it's quite reasonable to be able to use build-perl-modules within the package build in a case like this - indeed, I have it working with some small modifications.

I think the problem comes because Encode::Detect wants Module::Build as a dependency, but can't pull it in. The solution is to simply install Module::Build before installing Encode::Detect and it will no longer need to try to use CPAN.

Even if the CPAN dependency worked I think it might be better to pull in a specific version in build-perl-modules anyway - that way it will at least be the same combination of module versions that everyone else is using, perhaps lessoning the support burden if ever a problem was encountered with a specific Encode::Detect/Module::Build combo.

Note that bug 6143 is also somewhat related in that it covers another missing required dependency for SC7 (GD).

So the theory is, if you're installing on a distro that we don't natively support, that you can install perl modules.

Advice from the linux brains in the community about how to 'fix' this bug is always welcome, but we're just not going to sweat this at the moment.