in reply to unable to make manifest with symlinks

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. —— https://www.gnu.org/prep/standards/standards.html, section 7.3 "Making Releases"

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

  • Comment on Re: unable to make manifest with symlinks

Replies are listed 'Best First'.
Re^2: unable to make manifest with symlinks
by daxim (Curate) on Oct 24, 2019 at 13:22 UTC
    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.

        No, ".lnk" files are shell links; those go back to Windows 95.

      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...

        what are the commands for using them?
        mklink, fsutil, ln (in the Windows Resource Kit), ln (3rd party)
Re^2: unable to make manifest with symlinks
by mvsjes2 (Initiate) on Oct 24, 2019 at 02:48 UTC
    Thanks for the insight, that makes sense. I will refactor the 't' directory. It seemed like such a good idea at the time...