Opened 11 years ago
Closed 11 years ago
#9991 closed bug (fixed)
HaikuPM: perl - cannot install modules with cpan shell
Reported by: | zzzzz | Owned by: | zooey |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta1 |
Component: | Applications/Command Line Tools | Version: | R1/Package Management |
Keywords: | perl, cpan, modules | Cc: | |
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
Perl is in a completely unusable state on the PM branch. Modules cannot be installed. Layout is broken, see attached file.
Attachments (1)
Change History (9)
by , 11 years ago
Attachment: | perl-V.txt added |
---|
comment:1 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 11 years ago
A first look reveals that this is actually a generated file (storing the configuration settings). It is just created in the wrong place. On openSUSE Linux with perl 5.16 the file is created as $HOME/.cpan/CPAN/MyConfig.pm
.
comment:3 by , 11 years ago
Maybe I'm just accustomed to old /boot/common/ layout, which seems to be with haiku since the very beginning. And those dots in folder names... Is it Haiku's hidden directory, like Unix?
On my Slackware Linux box include array @INC default value is as follows:
@INC: /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5 /usr/share/perl5 .
Manually installed modules (site_perl), for example from cpan shell with sudo, go into /usr/local hierarchy. Those pre-packaged should go into vendor_perl directories. By saying that layout is broken I wanted to say that in the current HaikuPM layout the 'site_perl' part for manual installation falls below /packaged directory, which for me is not logical. Please correct me if I'm wrong, but shouldn't it be somewhere else, somewhere outside, at least for manually installed modules (aka site_perl), which have nothing in common with packaging? Or is it my misunderstanding of new package management internals?
On HaikuPM 'site_perl' part of @INC looks like this:
/packages/perl-5.10.1-5/.self/non-packaged/lib/perl5/site_perl/5.10.1/BePC-haiku /packages/perl-5.10.1-5/.self/non-packaged/lib/perl5/site_perl/5.10.1 .
Anyway, the critical issue here is the inability to build/install perl modules. And supposedly the CPAN/Config.pm is on place, still default installation place for modules will be below this /packages directory.
BTW, default per user config in $HOME/.cpan/CPAN/MyConfig.pm is typically generated upon first run of cpan shell. But this HaikuPM cpan is /boot/common/bin/cpan? Why not /packages/perl-5.10.1-5/.self/bin/cpan?
follow-up: 5 comment:4 by , 11 years ago
"/packages/<package>/.self" is a symlink that always refers to the installation location of the package in question. It allows hard-coding absolute paths at build time while still allowing the package to be installed in either of the three installation locations.
By default perl is installed in "/boot/common". So your site perl is "/boot/common/non-packaged/lib/perl5/site_perl/...", which is intended. The "non-packaged" directories in "/boot/common" and "/boot/home/config" are the base for a writable directory hierarchy, while most of the sibling directories are read-only (save for a few exceptions like "settings", "cache", and "var").
So the @INC
paths look OK, I guess. I'm not sure about the vendor perl directories. We might want to consider changing those to explicitly list both "/boot/common/..." and "/boot/home/config/...", so one can install packaged perl modules in home, even if perl itself is installed in common.
comment:5 by , 11 years ago
Thank you for the explanation.
The "non-packaged" directories in "/boot/common" and "/boot/home/config" are the base for a writable directory hierarchy, while most of the sibling directories are read-only (save for a few exceptions like "settings", "cache", and "var").
Maybe some files (and this Config.pm) are set read-only after the build, tried to be modified afterwards, but error is silent and changes don't follow?
So the
@INC
paths look OK, I guess. I'm not sure about the vendor perl directories. We might want to consider changing those to explicitly list both "/boot/common/..." and "/boot/home/config/...", so one can install packaged perl modules in home, even if perl itself is installed in common.
Sounds ok for me, but is it futureproof? Will the changes be needed when multiuser haiku is developed? In my opinion vendor_perl should be available only for packaged perl-based software and thus system-wide only. Explicitly listed both "/boot/common/..." and "/boot/home/config/..." reflect the 'sudo' cpan usage scenario on Linux, and the 'local::lib' usage scenario. For single-user it doesn't really matter, but for more users it would be great if they could install their own modules independently.
And finally, can we just create CPAN::Config by hand with proper values as a workaround?
comment:6 by , 11 years ago
Summary: | HaikuPM: perl heavily crippled → HaikuPM: perl - cannot install modules with cpan shell |
---|
I managed to build perl-5.18.1 from updated recipe from HaikuPorter. Installing modules from CPAN works fine here, with some minor issues:
1) installing needs restart (cannot commit transaction) 2) on cpan shell's first run it moans about not-writable locations. However, no further action is needed 3) installing ExtUtils::MakeMaker-based modules results with doc-install-error (ignorable), due to missing perllocal.pod file. 4) rebuild of 5.18.1 fails when 5.18.1 is already installed (for unknown reason).
Anyway, I think it's worth to upgrade perl to 5.18.1 version.
comment:7 by , 11 years ago
comment:8 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
For some reason the CPAN/Config.pm module is missing. I don't understand what you mean by "layout is broken". Please clarify.