Bugzilla – Bug 6389
Missing perl dependencies (GD/Module::Build)
Last modified: 2011-03-16 04:39:18 UTC
I'm putting together a SC7 ebuild for Gentoo which has involved me installing SC7 onto a pretty clean basic install of Gentoo. In getting that running I've discovered that I think the following CPAN modules are not included when they should be (with perhaps an additional step necessary in build-perl-modules): 1. GD. This, of course, also relies on libgd. 2. Module::Build. I found that without this the Encode::Detect module failed to build in build-perl-modules as it wanted to go to CPAN for Module::Build as a dependency, but CPAN wasn't set up on this clean machine. This is with the 2007-12-13 nightly. I tried adding Module::Build to build-perl-modules but because the ordering is alphabetical rather than manual it didn't want to install before Encode::Detect. It therefore manually installed it before kicking off build-perl-modules again - thus, there may be other dependencies that I've not yet discovered because bringing in Module::Build pulls in a load of other things. I can work around these things in the ebuild, but I suspect they'll be problems on other platforms too. As an aside, I don't know why the ordering isn't manually defined in build-perl-modules - having it sorted alphabetically seems unnecessarily restrictive and also leads to the kludge to get DBI installed early.
I've never used Gentoo or ebuild, but... IMO, any linux "package" should be written to "just work" without the user needing to run build-perl-modules. Both GD and Encode::Detect are arch-specific modules included under CPAN/arch/... I'd try to figure out why Gentoo can't find those modules. What arch are you running on? What version of perl does Gentoo have? Is it threaded? The output when you start SC with --d_startup will probably be helpful. You might want to start a thread on the devel list to continue this discussion.
Sorry, I think I should have explained a little clearer. Gentoo is a source distribution and so the same package must compile and install on any number of different architectures (x86, ia_64, mips, arm, ppc etc etc), and with/without Perl threading etc. Hence the ebuild (which is essentially a Bash script to download and install a package) uses the "no-cpan-arch" tarball. Because of this I believe it has no choice but to build the perl modules to get the non-Perl bits of those modules built. So, I think the problem still stands for those who aren't using one of the pre-rolled arch tarballs.
Interesting. I was aware that Gentoo is a source distribution but I don't know much about how it works. You may find a couple of bugs that I previously filed to be useful as you move forward: Bug 5882: build-perl-modules.pl can't build Encode-Detect on new linux install Bug 6143: Add GD to build-perl-modules.pl Does Portage have the concept of dependencies like RPM and deb? If so, can't you just tell it you need perl(GD) and it'll go get it, compile it and install it without using build-perl-modules? It's also worth noting that Andy recently changed the deb package to use all the bundled CPAN modules (including the arch-specific ones) instead of pulling them in as deps because they had too many support issues due to old versions of the required modules. The new RPM that I worked on does the same. I don't know if it's even possible with Gentoo, but you may find that downloading and installing the precompiled modules works for most of your users and saves a lot of headaches. Good luck.
Sorry, yes, those other two bugs cover it so I think this could be closed as a duplicate. I'll add something to each of those bugs as they exactly cover the two issues I've re-raised here. I think the approach for the deb is the right one - having them bundled with the build is the only reliable thing to do: 1. Not all the required Perl modules are available as separate packages within Gentoo's package system. We could request them, but dealing with the Perl package maintainers will be a complexity we could do without. 2. SqueezeCenter wants some pretty specific versions and throws a wobbler if you have a different version. Those specific versions may not be available in the Gentoo package repository (and even if they are, they may not be relied on to stay there as they tend to get aged out to leave just the most recent 4-5 versions). 3. It would mean we need to closely monitor the Perl module versions that SqueezeCenter wants over each new version and update the build to get the right versions each time. Again, sorry for duplicating this - I really should get better with the search.
*** This bug has been marked as a duplicate of 6143 ***