[cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

[Raffi Enficiaud]

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.