mvsjes2 has asked for the wisdom of the Perl Monks concerning the following question:

I'm setting up a package for distribution on CPAN for the first time. I have a few symlinks in my testing directory. When I try running 'make manifest' or other related commands that invoke ExtUtils::Manifest, I get an error saying "...Google-RestApi/t/integration/Google/integration is encountered a second time at /usr/share/perl/5.26/File/ line 79." 'integration' is a symlink. I can't be the only person that has symlinks in a dist. :-/ There is a mention of a similar problem here: but there doesn't seem to be a resolution.

I've upgraded ExtUtils::Manifest to 1.72.

The project is at

Could someone give me a shove in the right direction on this?

Replies are listed 'Best First'.
Re: unable to make manifest with symlinks
by stevieb (Canon) on Oct 23, 2019 at 19:14 UTC

    What are you symlinking to? Something located within the distribution somewhere?

    If it's outside of the distribution it'll be useless to others anyhow, so perhaps add the symlink to the MANIFEST.SKIP file (just create it if it doesn't exist within your distribution's root.

      It's symlinking to other dirs within the same dist. I'm just symlinking to a couple of 'lib' dirs to perl modules so my test files won't have to 'use lib "$FindBin::RealBin/../../../../../../../whatever". I have a symlink so if I move stuff around within the tests I can just update one symlink and the tests will continue to resolve the use statements properly. It's a convenience thing, I can work around it, but I'm puzzled why I'd run into this problem in the first place.

        Might I ask the reasoning behind doing things this way?

        In no way do I mean disrespect, but this has the "X-Y Problem" phenomenon written all over it. As someone who was also once a first-time CPAN contributor (always seeking ways to do ingenious things at that), there are sometimes more efficient ways of doing things we might not have thought of yet.

        I've had a look at your Github repo, and it looks sane, except you've got extra stuff in t/ directory which looks a bit odd. Could you explain your reasoning behind why you've done things this way?

        Perhaps instead of helping fix a symlink problem (which, by the number of responses doesn't seem like it's gaining traction), we could assist with easing your directory layout situation, possibly with automation using the build system or even the tests themselves.


Re: unable to make manifest with symlinks
by jcb (Vicar) on Oct 23, 2019 at 23:37 UTC

    You are not supposed to put symlinks in a CPAN distribution because symlinks are not portable. Even some (very old and probably now obsolete) Unix systems did not support symlinks and modern Windows still lacks the feature.

    To this day, the GNU coding standards still have the following:

    Donít include any symbolic links in the distribution itself. If the tar file contains symbolic links, then people cannot even unpack it on systems that donít support symbolic links. Also, donít use multiple names for one file in different directories, because certain file systems cannot handle this and that prevents unpacking the distribution. ——, section 7.3 "Making Releases"

    I see no reason not to follow that advice for CPAN as well.

      modern Windows still lacks the feature
      That's not right. Windows 2000 (and later) had junctions and Windows XP (and later) had symlinks.
        True, but because of Windows' usage of file type as part of the file name, its ".lnk" files are still different from Unix' symlinks.

        Interesting, yet they are either rarely used or not really what they look like. I am not surprised that NTFS has added such features, but I am fairly sure that there are limitations.

        If I recall correctly, junctions can only refer to directories and are more like Linux's bind mounts than POSIX symlinks or hardlinks, including a requirement for special privilege to create them.

        If XP added true symlinks, what are the commands for using them? I doubt that ln -s works...

      Thanks for the insight, that makes sense. I will refactor the 't' directory. It seemed like such a good idea at the time...