Symlinks can't be copied by install_subdir() since 0.47.0

[Marco Trevisan (Treviño)]

As per upstream bug: https://github.com/mesonbuild/meson/issues/3914

If you have a dangling symlink (the symlink is referencing a path that is coming from another package on the system, so only resolved once installed on the system), in a directory, install_subdir is now reporting a stacktrace since the minstall.py rewrite (worked fine with 0.46, failing since 0.47.0 and still on 0.47.1).

[Launchpad Janitor (janitor)]

This bug was fixed in the package meson - 0.47.1-1ubuntu3

---------------
meson (0.47.1-1ubuntu3) cosmic; urgency=medium

  * debian/patches/install_subdir-Also-copy-dangling-symlinks.patch,
    debian/patches/0001-minstall-never-try-to-set-chmod-on-symlinks.patch,
    debian/patches/0002-minstall-never-follow-symlinks-when-setting-ownershi.patch,
    debian/patches/0003-minstall-use-follow_symlinks-to-check-executable.patch:
    - Fix symlink copy when using install_subdir (LP: #1787286)

 -- Marco Trevisan (Treviño) <email address hidden> Mon, 20 Aug 2018 16:54:15 +0200

[Dimitri John Ledkov (xnox)]

I believe this has broken systemd build.

It has the following in the source tree:
./units/basic.target
./test/basic.target -> ../units/basic.target

and in ./test/meson.build it does
install_data(file, install_dir : testsdir + '/testdata/')

previously basic.target (from ./test/) would be copied and would create a regular file in target.
now it copies basic.target as a symlink, and a broken symlink is installed in target.

I'll check if systemd has any fixes for this, and i guess will test meson master or somesuch.