Le 18/04/15 09:34, Domen Vrankar a écrit :
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
Ok. I worked essentially on having the tests kind of functional. I will
add the cases you mentioned in new tests.
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.
Ok, I will try.
- 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.
Ok.
You are also leaving trailing whitespaces in patches - those should be removed.
I will clean the code, yes.
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.
I hope so. The added value in the tests I wrote so far is the
possibility to inspect the generated packages with the Debian tools, and
some refactoring (I found difficult to have several config files and one
check file for all generators).
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).
I agree with that.
- 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.
Good.
Raffi.
--
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
