[Pkg-cmake-team] Bug#868584: debhelper: please disable user package registry for CMake builds

[Christian Seiler]

Package: debhelper
Version: 10.2.5
Severity: important
Control: affects -1 cmake
X-Debbugs-Cc: pkg-cmake-team at lists.alioth.debian.org

Dear debhelper Maintainers,
(Cc'ing CMake packaging list as this affects them)

I just stubmled upon a feature added to CMake 3.x that allows packages
to register in a "package registry" via the export() CMake command.
This causes CMake to write into the home dirctory of a user. I believe
this is not desireable when building Debian packages - the registry in
the home directory should be ignored. When looking for packages only
the system registry should be queried (but that does need to happen,
otherwise builds may break), and the export() command should be
disabled completely.

Documentation for this:

https://cmake.org/cmake/help/v3.9/manual/cmake-packages.7.html#package-registry
https://cmake.org/cmake/help/v3.0/command/export.html
https://cmake.org/cmake/help/v3.9/manual/cmake-packages.7.html#disabling-the-package-registry
https://cmake.org/Bug/view.php?id=14849

It should be sufficient to pass

  -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
  -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON

to the CMake invocation. (Though I haven't gotten around to testing
this yet, hence no patch attached here so far.)

If you look for packages that use CMake as their build system _and_
have export(PACKAGE in any CMakeLists.txt file [1], then you will find
that the current build logs already show a warning message that the
non-existent home directory of the buildd user on the autobuilders
couldn't be written to. Some examples of this:

https://buildd.debian.org/status/fetch.php?pkg=mapserver&arch=arm64&ver=7.0.6-2&stamp=1498513871&raw=0
https://buildd.debian.org/status/fetch.php?pkg=avogadro&arch=amd64&ver=1.2.0-2&stamp=1499360655&raw=0
https://buildd.debian.org/status/fetch.php?pkg=freerdp2&arch=amd64&ver=2.0.0%7Egit20161130.1.e60d0d5%2Bdfsg1-1&stamp=1482840273&raw=0
https://buildd.debian.org/status/fetch.php?pkg=armadillo&arch=arm64&ver=1%3A7.950.1%2Bdfsg-1&stamp=1497978266&raw=0
https://buildd.debian.org/status/fetch.php?pkg=octomap&arch=arm64&ver=1.8.1%2Bdfsg-1&stamp=1485272067&raw=0
https://buildd.debian.org/status/fetch.php?pkg=yaml-cpp&arch=arm64&ver=0.5.2-4&stamp=1476324483&raw=0
https://buildd.debian.org/status/fetch.php?pkg=orocos-kdl&arch=arm64&ver=1.3.1%2Bdfsg-1&stamp=1468048292&raw=0
https://buildd.debian.org/status/fetch.php?pkg=libwebsockets&arch=arm64&ver=2.0.3-2&stamp=1478209995&raw=0
https://buildd.debian.org/status/fetch.php?pkg=vtk-dicom&arch=arm64&ver=0.7.10-1%2Bb2&stamp=1487960322&raw=0
https://buildd.debian.org/status/fetch.php?pkg=gli&arch=all&ver=0.8.2.0%2Bds1-2&stamp=1484226906&raw=0
https://buildd.debian.org/status/fetch.php?pkg=diskscan&arch=arm64&ver=0.19-4&stamp=1484043493&raw=0

(Look for "Cannot create package registry file:" in the log.)

Additionally, _all_ packages that use CMake and call find_package()
(the vast majority of CMake-using packages) will be affected if a user
has entries in their local user registry that have the same name as
system packages.

Regards,
Christian

PS: I'm unsure about the severity of this bug. I believe this should
qualify as RC (policy violation: writing to home directories), but
I've left it at "important" for now.

[1] Codesearch expression:

  path:.*/CMakeLists.txt export\(PACKAGE

Note that there are false positives if you use that expression, as
sometimes unused bundled libraries are shown, and sometimes the package
is built within Debian with a different build system (e.g. autotools)
instead of CMake. (If the package supports multiple build systems.)

-- System Information:
Debian Release: 9.0
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev            20161112.1
ii  binutils                 2.28-5
ii  dh-autoreconf            14
ii  dh-strip-nondeterminism  0.034-1
ii  dpkg                     1.18.24
ii  dpkg-dev                 1.18.24
ii  file                     1:5.30-1
ii  libdpkg-perl             1.18.24
ii  man-db                   2.7.6.1-2
ii  perl                     5.24.1-3
ii  po-debconf               1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201608

-- no debconf information