CPack DEB generator is following symlinks of directories

Code
1

The following link indicates this issue was fixed: https://gitlab.kitware.com/cmake/cmake/issues/19448

But, for me it still remains with CMake v3.15.7.

The following code illustrates the issue:

install(CODE "
    EXECUTE_PROCESS(
        COMMAND ${CMAKE_COMMAND} -E create_symlink
            /lib/x86_64-linux-gnu
            lib64
        WORKING_DIRECTORY \$ENV{DESTDIR}
    )
    EXECUTE_PROCESS(
        COMMAND ${CMAKE_COMMAND} -E create_symlink
            /usr/lib/x86_64-linux-gnu
            lib64
        WORKING_DIRECTORY \$ENV{DESTDIR}/usr
    )"
    COMPONENT ${PROJECT_NAME}
)

This installs two symlinks. I can see the symlinks are correct in the temporary _CPack_Packages directory structure when CPack is executed. However, looking at the contents of data.tar.gz with Archive Manger I see the following:
Screenshot from 2020-04-16 12-38-20|594x247

2

Hmm. Something may have changed in libarchive. @brad.king @kyle.edwards

3

I cannot reproduce this with CMake 3.15.7:

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.15)
project(Issue12284 NONE)
include(CPack)

install(CODE [[
  execute_process(
    COMMAND ${CMAKE_COMMAND} -E create_symlink /lib/x86_64-linux-gnu lib64
    WORKING_DIRECTORY $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}
  )
  file(MAKE_DIRECTORY "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/usr")
  execute_process(
    COMMAND ${CMAKE_COMMAND} -E create_symlink /usr/lib/x86_64-linux-gnu lib64
    WORKING_DIRECTORY $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/usr
  )
]])
$ cmake ..
$ make
$ cpack -G TGZ
$ tar tzf Issue12284-0.1.1-Linux.tar.gz
Issue12284-0.1.1-Linux/lib64
Issue12284-0.1.1-Linux/usr/
Issue12284-0.1.1-Linux/usr/lib64
4

Here’s how to duplicate it:

cmake_minimum_required(VERSION 3.15)
project(Issue12284 NONE)

install(CODE [[
  execute_process(
    COMMAND ${CMAKE_COMMAND} -E create_symlink /lib/x86_64-linux-gnu lib64
    WORKING_DIRECTORY $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}
  )
  file(MAKE_DIRECTORY "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/usr")
  execute_process(
    COMMAND ${CMAKE_COMMAND} -E create_symlink /usr/lib/x86_64-linux-gnu lib64
    WORKING_DIRECTORY $ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/usr
  )
]])

set(CPACK_DEBIAN_PACKAGE_DESCRIPTION "Test Package")
set(CPACK_DEBIAN_FILE_NAME ${PROGRAM_NAME})
set(CPACK_DEBIAN_PACKAGE_ARCHITECTURE x86-64)

set(CPACK_GENERATOR DEB)
set(CPACK_PACKAGE_VERSION_MAJOR 1)
set(CPACK_PACKAGE_VERSION_MINOR 0)
set(CPACK_PACKAGE_VERSION_PATCH 0)
set(CPACK_PACKAGE_VERSION 1.0.0)
set(CPACK_DEBIAN_PACKAGE_MAINTAINER "package-maintainer <package-maintainer@xyz.com>")
set(CPACK_PACKAGE_VENDOR xyz)

include(CPack)

$ cmake ..
$ cpack
5

This somehow reminds me of https://gitlab.kitware.com/cmake/cmake/-/issues/19419

Eike

6

@DKLind thanks. Please see the fix in CMake MR 4637.

7

@brad.king Yes, that fixes the problem, thank You!

Is this fix going to rolled into the 3.15.x code branch or only 3.17.x?

8

I had scheduled it for 3.18 since this is a long-standing bug and not a regression. I’ve updated the merge request to backport the fix to the 3.17 series, but we probably won’t port it back further.

9

I’ll watch for a 3.17.2 release. Meanwhile, I’ll just patch the source.

Thanks