#39384 closed defect (fixed)
ikiwiki port installs perllocal.pod
| Reported by: | geekosaur | Owned by: | ryandesign (Ryan Carsten Schmidt) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.1.3 |
| Keywords: | Cc: | cooljeanius (Eric Gallager) | |
| Port: | ikiwiki |
Description
I am under the impression that Perl ports are not supposed to try to create e.g. /opt/local/lib/perl5/5.12.4/darwin-thread-multi-2level/perllocal.pod? The ikiwiki port just gave me
Error: org.macports.activate for port ikiwiki returned: Image error: /opt/local/lib/perl5/5.12.4/darwin-thread-multi-2level/perllocal.pod already exists and does not belong to a registered port. Unable to activate port ikiwiki. Use 'port -f activate ikiwiki' to force the activation.
(that having been created by a local CPAN install of extension modules for re.pl).
Change History (6)
comment:1 Changed 11 years ago by cooljeanius (Eric Gallager)
| Cc: | egall@… added |
|---|
comment:2 Changed 11 years ago by mf2k (Frank Schima)
| Cc: | tommyd@… removed |
|---|---|
| Keywords: | perllocal.pod removed |
tommyd has retired based on email communication 8/28/2013.
comment:3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
| Owner: | changed from macports-tickets@… to ryandesign@… |
|---|---|
| Status: | new → assigned |
comment:4 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:5 Changed 10 years ago by cooljeanius (Eric Gallager)
Thinking of perllocal.pod files in general, one approach to them to consider could be Fink's, where there is a podfiles directory in ${prefix}/share where all perllocal.pod files get put with the naming scheme of perllocal.${name}.pod. So for example, if MacPorts had used that approach in this case, the perllocal.pod file would get installed as /opt/local/share/podfiles/perllocal.ikiwiki.pod. Along with the ShuX pod viewer from CamelBones, having all the perllocal.pod files organized in a single directory like that can make for an easy way to get a quick summary of all the perl modules installed in that prefix. Although taking that approach would probably require messing with the perl5 PortGroup, so I guess it would probably be easier to just keep deleting the perllocal.pod files like this in the meantime...
comment:6 Changed 10 years ago by geekosaur
For what it's worth, when addressing this for the local perl distribution at a previous job, I used perllocal.pod.d/collectionname and then built perllocal.pod in a separate step during nightly update processing. Local installs (e.g. cpan) were handled by having that install to perllocal.pod.d/perlocal.pod and appending that to the final perllocal.pod.
Cc Me!