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

Raffi Enficiaud raffi.enficiaud at mines-paris.org
Tue Apr 28 07:53:37 EDT 2015


Le 28/04/15 12:23, Domen Vrankar a écrit :
> 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
>

Hi,

I'll resubmit the patches then.

Best,
Raffi




More information about the cmake-developers mailing list