[CMake] CMake & RPM problems

[Eric Noulard]

2009/5/10 Alexander Neundorf <a.neundorf-work at gmx.net>:
> On Sunday 10 May 2009, Eric Noulard wrote:

>>
>> Currently the INSTALL(SCRIPT/CODE ... ) script is too loose, moreover
>> as far as I know there aren't any "uninstall rules"...
>>
>> So currently I think we can get INSTALL(SCRIPT/CODE ... ) to be embedded
>> into RPM post-install rules, I do have to find where thoses scripts
>> are generated though.
>>
>> There will be several remaining issues:
>>     1) You usually don't want to run "INSTALL(SCRIPT/CODE ... )" when
>> building the RPM, however now since CPack basically do install with
>> relocation they are.
>
> Hmm, yes, usually, but maybe sometimes you do want to run them...

Yes agreed, but may be you should have the choice to launch them or not,
currently I think you do not have choice.
In fact you may want to specify that you DO want to run those scripts
if you do "make install"
but not if do "install" from within CPack.

In fact if CPack generator were running in some kind of chroot-ed
env it would be OK but currently, updating icon-cache  or menu entry
because you are **building** a package is plain wrong.


>>     2) There is no associated "uninstall" rules, which is just bad
>> because you may
>>          leave dangling menu entry and/or icon.
>
> Hmm ?

In package like RPMs you usually have symmetric  postinstall /
postuninstall actions.

e.g.:
postinstall --> install a freedesktop menu entry
postuninsrall (or may be preuninstall) --> uninstall the freedesktop menu entry

With the current "INSTALL(SCRIPT/CODE" thing you do not have way to
specify "UNINSTALL(SCRIPT/CODE"), this is basically because there is no

[make] uninstall target generated by cmake.

in fact

INSTALL(SCRIPT file) would better be:

INSTALL(SCRIPT doit.cmake
                 UNSCRIPT undoit.cmake)

the "UNSCRIPT" part should be optionnal.

We should even have POST-SCRIPT POST-UNSCRIPT, PRE-SCRIPT, PRE-UNSCRIPT
if we want to know WHEN those install-time actions will take place.

The fact is I don't know if it's CMake job to do "install-time" actions,
but this is definitely a essential functions of package format
(RPM, NSIS, DEB,  etc...)
those formats comes with their own "install-time scripts language".
should we import the feature into CMake INSTALL(SCRIPT/UNSCRIPT) ?

My opinion is, I don't think so, but I may be wrong.
I would rather have trap-door to "native" package format scripts with
CPACK_RPM_XXX
CPACK_DEB_XXX
CPACK_NSIS_XXX

What do (all) you think?

>> Alex,
>> Does KDE uses INSTALL(SCRIPT/CODE ... ) ?
>
> Yes.
>
>> If yes how do packager do for handling that in DEB, RPM ... ?
>
> This is done completely independent.
> The official distribution packager build their packages themselves anyway.

That's why I wanted to support "custom spec file" with the CPack RPM generator,
this way if the CPack RPM -generated spec file is not "good enough" one
may use it's custom made one.

It's about the same kind of discussion we had about DEB generator being accepted
by debian developers. I think packager is a plain job in itself and
may be CPack
won't ever be good enough to be the working tool of packagers.

However I think CPack (RPM, DEB, NSIS, etc...) should give "enough" control
to newbie packager in order to get "not so bad" packages out-of-the-box.

Concerning CPack RPM what about commiting
http://public.kitware.com/Bug/view.php?id=8988 to HEAD?


-- 
Erk