Debian package for liblsl depends on itself.

[stellarpower]

I have downloaded the liblsl package for focal, and I cannot install it:

# gdebi /tmp/liblsl-1.16.1-focal_amd64.deb 
Reading package lists... Done
Building dependency tree        
Reading state information... Done
Reading state information... Done
This package is uninstallable
Dependency is not satisfiable: liblsl (= 1.16.1-focal)

If I look at the control file:

Architecture: amd64
Depends: **liblsl (= 1.16.1-focal)**, libc6 (>= 2.29), libgcc-s1 (>= 3.0), libpugixml1v5 (>= 1.6), libstdc++6 (>= 7)
Description: Labstreaminglayer C/C++ library
 Labstreaminglayer C/C++ library
...
Version: 1.16.1-focal

It seems likely the problem is caused by the issue that the package depends on itself. I had to forcibly install it using dpkg, and then go back again with gdebi to get the dependencies installed, which was now able to complete because the same package it was trying to install was on the system already.

[cboulay]

If I had to guess, I'd say it's due to this block of CMake script. If you are able, can you help narrow it down?

[stellarpower]

I haven't encountered creation of the debian package structure directly through CMake before, which is interesting.

I don't have time to set up build environment just now, but I'd hazard a guess the simplest solution:

list(REMOVE_ITEM LSLDEPENDS ${component})

if it's winding up including itself in the list.

[tstenner]

Interesting problem. dpkg itself installs the problem without any warning, but other dpkg frontends can get confused.

liblsl gets added to the dependencies by default because the automatic package dependency discovery doesn't work for libraries built in the same step. This should just need a single if to skip it for liblsl:

diff --git a/cmake/LSLCMake.cmake b/cmake/LSLCMake.cmake
index 665aeb4..f64b001 100644
--- a/cmake/LSLCMake.cmake
+++ b/cmake/LSLCMake.cmake
@@ -137,8 +137,9 @@ function(installLSLApp target)
                install(CODE "file(INSTALL $<TARGET_FILE:${libdependency}> DESTINATION \${CMAKE_INSTALL_PREFIX}/$<IF:$<PLATFORM_ID:Windows>,${CMAKE_INSTALL_BINDIR},${CMAKE_INSTALL_LIBDIR}>)")
        endforeach()

-       set_property(GLOBAL APPEND PROPERTY
-               "LSLDEPENDS_${PROJECT_NAME}" liblsl)
+       if(NOT PROJECT_NAME STREQUAL "liblsl")
+               set_property(GLOBAL APPEND PROPERTY "LSLDEPENDS_${PROJECT_NAME}" liblsl)
+       endif()
        install(TARGETS ${target} COMPONENT ${PROJECT_NAME}
                RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
                LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}

Result:

$ dpkg -I liblsl-1.16.1-jammy_amd64.deb 
 new Debian package, version 2.0.
 size 483994 bytes: control archive=992 bytes.
     348 bytes,    12 lines      control              
     988 bytes,    16 lines      md5sums              
      64 bytes,     7 lines   *  postinst             #!/bin/sh
      61 bytes,     7 lines   *  postrm               #!/bin/sh
      33 bytes,     1 lines      shlibs               
 Architecture: amd64
 Depends: libc6 (>= 2.34), libgcc-s1 (>= 3.0), libstdc++6 (>= 12)

[stellarpower]

Yeah, I figured that might be why - other tools do depend on the library. Either an if statement or removing the current package name should work.

Also, FYI, the reason dpkg works is it doesn't check or attempt to fetch dependencies. Installing breaks my system and it does tell me this, bit goes ahead and does it anyway, whilst gdebi refuses to continue with constraints it can't satisfy. I presume using apt would find the same, were the package in e.g. a PPA.