>> I added the following functionalities: >> - set the permissions of the md5sum to RW-R--R--, because lintian >> complains >> - added an option to set the shlibdeps per component >> - added an option to set the dependencies per component >> - added an option to set the description per component
The way you implemented it you are not covering the case: 1) CPACK_DEBIAN_PACKAGE_DESCRIPTION no set 2) CPACK_DEBIAN_PACKAGE_DESCRIPTION is set with component description 3) next component doesn't set per component description so CPACK_DEBIAN_PACKAGE_DESCRIPTION is not reset and description of the previous component is used Or if 1) would be set and 3 not set you would loose the initial description There is a simple solution for variables overflowing between components - just wrap the entire code into a function (see CPackRPM cpack_rpm_generate_package() function) - since such a change messes up the entire diff (indentations) this should be an entirely separate patch. This solution would also simplify the shlibdeps patch since you would no longer need to set CPACK_DEBIAN_PACKAGE_AUTO_DEPENDS to empty value and unset it when you no longer need it. >> - enforcing the lower case policy of Debian for package names (in the >> file, due to the comment "# debian policy enforce lower case for package >> name") Since you are fixing multiple non related issues at the same time please split the patch into separate commits so that it can easier be seen which change fixes which issue. You are also leaving trailing whitespaces in patches - those should be removed. >> On the other hand, I started writing tests based on the one existing for >> the CPackComponentsAll, but specific to debian packages: >> - added a function for running lintian and checking for some errors. The >> md5sum permission change is now covered by that >> - added a function for running dpkg-deb and extracting a particular >> field of the package metadata. No change I made are currently covered by >> this function, this is what I will do next. >> - Having one specific check file per configuration, sharing a common >> .cmake providing the check functions (linitian and dpkg-deb). This would >> prevent the cluttering of the checks that we can observe in the >> CPackComponentsAll final test. I already wrote to the mailing list regarding changing where and how CPack test should be written but it will take me a few days to implement... Since you are already splitting tests into separate scripts it will be easy to move them later on. > Sorry that was too quick. Here are the open questions: > - if a component depends on another component, should we add the dependency > automatically? I'd say no by default so that we don't break back compatibility unnecessarily but the feature should be enabled through a variable (e.g. CPACK_DEBIAN_COMPONENTS_AUTODEPEND ON - and also per component version). > - What about the version of this dependency? > > Let's say I have components A and B, and B depends on A. I am at version X. > Dependencies of A are d11, d12, d1N, > Dependencies of B are d21, d22, d2P > > Should the generation of the package B include d2(P+1)= "A (= versionX)" ? For the first patch I would omit versions of dependencies. Later this can be added with additional possibility to change = to >= for adding minimal required version (e.g. CPACK_DEBIAN_COMPONENT_<name>_DEPENDS_<dependency> some_version) with the possibility to enable/disable version addition. Thanks, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
