MantisBT - CMake
View Issue Details
0013231CMakeCPackpublic2012-05-17 00:052015-11-02 09:15
Jess 
Raffi Enficiaud 
normalminoralways
closedfixed 
LinuxUbuntu 64-bit12.04
CMake 2.8.7 
CMake 3.3 
0013231: CPackDeb incorrectly "leaks" Debian dependencies across components
Dependency generation in the Debian
control file using the CPACK_DEBIAN_PACKAGE_SHLIBS flag does not work correctly for components. Dependencies
are generated, however each component is incorrectly
assigned all previously processed components' dependencies on top of
its own. This occurs regardless of whether the user explicitly
set any (additional) dependencies via CPACK_DEBIAN_PACKAGE_DEPENDS.


3 components,
   Comp1 has dependencies A, B, C, Comp3
   Comp2 has dependencies D, E, F, Comp3
   Comp3 has dependencies G

relevant config:
set(CPACK_COMPONENTS_IGNORE_GROUPS TRUE)
set(CPACK_DEB_COMPONENT_INSTALL TRUE)
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS TRUE)

We have no way of expressing dependencies between components for the
purposes of Debian packaging (so far as I know) so Comp1 and Comp2 depending
on Comp3 is not achievable. That aside, if CMake processes Comp1 then Comp2, then Comp3, the
resultant Debian package Comp1 will depend on A, B, C, package Comp2 (incorrectly)
on A, B, C, D, E, F and package Comp3 (incorrectly) on A, B, C, D, E, F,
G.
To fix I patched the CPackDeb.cmake script as follows, introducing new
per-component user-defined dependency variable
CPACK_DEB_<component>_PACKAGE_DEPENDS, which should be used over
CPACK_DEBIAN_PACKAGE_DEPENDS if components are being used.

214,218c214,226
< IF (CPACK_DEBIAN_PACKAGE_DEPENDS)
< SET (CPACK_DEBIAN_PACKAGE_DEPENDS
"${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS},
${CPACK_DEBIAN_PACKAGE_DEPENDS}")
< ELSE (CPACK_DEBIAN_PACKAGE_DEPENDS)
< SET (CPACK_DEBIAN_PACKAGE_DEPENDS
"${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS}")
< ENDIF (CPACK_DEBIAN_PACKAGE_DEPENDS)
---
> IF(CPACK_DEB_PACKAGE_COMPONENT)
> IF (CPACK_DEB_${CPACK_DEB_PACKAGE_COMPONENT}_PACKAGE_DEPENDS)
> SET (CPACK_DEBIAN_PACKAGE_DEPENDS "${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS}, ${CPACK_DEB_${CPACK_DEB_PACKAGE_COMPONENT}_PACKAGE_DEPENDS}")
> ELSE (CPACK_DEB_${CPACK_DEB_PACKAGE_COMPONENT}_PACKAGE_DEPENDS)
> SET (CPACK_DEBIAN_PACKAGE_DEPENDS "${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS}")
> ENDIF (CPACK_DEB_${CPACK_DEB_PACKAGE_COMPONENT}_PACKAGE_DEPENDS)
> ELSE (CPACK_DEB_PACKAGE_COMPONENT)
> IF (CPACK_DEBIAN_PACKAGE_DEPENDS)
> SET (CPACK_DEBIAN_PACKAGE_DEPENDS "${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS}, ${CPACK_DEBIAN_PACKAGE_DEPENDS}")
> ELSE (CPACK_DEBIAN_PACKAGE_DEPENDS)
> SET (CPACK_DEBIAN_PACKAGE_DEPENDS "${CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS}")
> ENDIF (CPACK_DEBIAN_PACKAGE_DEPENDS)
> ENDIF (CPACK_DEB_PACKAGE_COMPONENT)
This config then will do the trick, also allowing 1 and 2's dependency
on 3 to be expressed:

set(CPACK_COMPONENTS_IGNORE_GROUPS TRUE)
set(CPACK_DEB_COMPONENT_INSTALL TRUE)
set(CPACK_DEB_1_PACKAGE_DEPENDS "myproject-3")
set(CPACK_DEB_2_PACKAGE_DEPENDS "myproject-3")
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS TRUE)
No tags attached.
related to 0012062closed Domen Vrankar CPackDeb: The EXTRA control files may not be specified on a per-component basis 
child of 0011944closed Raffi Enficiaud CPackDeb: Support dependencies between components/Debian packages 
Issue History
2012-05-17 00:05JessNew Issue
2012-05-23 05:29Eric NOULARDRelationship addedrelated to 0012062
2012-08-11 21:35David ColeStatusnew => backlog
2012-08-11 21:35David ColeNote Added: 0030424
2015-05-14 12:58Raffi EnficiaudAssigned To => Raffi Enficiaud
2015-05-14 12:58Raffi EnficiaudStatusbacklog => assigned
2015-05-14 12:59Raffi EnficiaudNote Added: 0038747
2015-05-14 13:00Raffi EnficiaudRelationship addedchild of 0011944
2015-05-18 11:34Domen VrankarNote Added: 0038766
2015-05-18 11:34Domen VrankarStatusassigned => resolved
2015-05-18 11:34Domen VrankarFixed in Version => CMake 3.3
2015-05-18 11:34Domen VrankarResolutionopen => fixed
2015-11-02 09:15Robert MaynardNote Added: 0039814
2015-11-02 09:15Robert MaynardStatusresolved => closed

Notes
(0030424)
David Cole   
2012-08-11 21:35   
Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0038747)
Raffi Enficiaud   
2015-05-14 12:59   
I believe this was fixed in next for 3.3 with the latest changes.
(0038766)
Domen Vrankar   
2015-05-18 11:34   
Fixed with commit:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=c8375e1 [^]
(0039814)
Robert Maynard   
2015-11-02 09:15   
Closing resolved issues that have not been updated in more than 4 months.