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

[Domen Vrankar]

Hi,

Sorry for not replying sooner.

> Please find attached a patch for the reworked documentation. I tried to make
> the doc more consistent with the CPackRPM (doc right after the variable
> declaration and options afterwards).
> I also put links for the variables and changed the formatting a bit.

Thanks for the patches. You are doing a great work but please start
splitting patches into subpatches... Each patch you provide is a
combination of fixing one thing and adding a bunch of new things to it
as well. Until one patch is added to master that patch is not finished
and should not be built upon with new patches that are remotely
related at best.

If you intend to provide the patches like that then rework the patches
yourself and resubmit all of them each time until they are applied.

> There are a couple of things though:
> - the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code

I'll take a look after we finish with current patches...

> - right now, the CPACK_COMPONENT_<COMP>_DESCRIPTION is used as an equivalent
> to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM
> conventions, those would be called CPACK_DEBIAN_<COMP>_PACKAGE_DESCRIPTION,
> which I find also better. However, in that case, should it default to
> CPACK_COMPONENT_<COMP>_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION?
> In fact CPACK_COMPONENT_<COMP>_DESCRIPTION and
> CPACK_DEBIAN_<COMP>_PACKAGE_DESCRIPTION would have the same purpose and I
> think that it will not be obvious for the user to cope with all those
> variables.

They would not have the same purpose - one is for setting value for
all package generators at once while the other is for debian specific
content.
I am not a fan of generator specific overrides so I haven't bugged you
with that entire hierarchy because it can be added later and because
you volunteered for completely different functionality in the first
place.
On the other hand that is the preferred way of Brad and Eric so I
intended to add the overrides later on.

Regards,
Domen