#9991: HaikuPM: perl heavily crippled -----------------------------------------------+--------------------------- Reporter: zzzzz | Owner: zooey Type: bug | Status: assigned Priority: normal | Milestone: R1/beta1 Component: Applications/Command Line Tools | Version: R1/Package Resolution: | Management Blocked By: | Keywords: Has a Patch: 0 | perl,cpan,modules | Blocking: | Platform: x86 -----------------------------------------------+--------------------------- Comment (by zzzzz): 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? -- Ticket URL: <http://dev.haiku-os.org/ticket/9991#comment:5> Haiku <http://dev.haiku-os.org> Haiku - the operating system.