Hi everyone,

I've been porting our commercial, in-house, unmaintainable Linux product build 
process to CMake.  It's been remarkably easy, but now I've hit a hurdle.

I need to produce an RPM that will install on both Red Hat 5 and Suse 11.  For 
political reasons I can't produce two distinct RPMs.  The executables are all 
happily statically linked so there isn't a problem with differing libraries.  
The problem is that there is an init script in my product, which wants to go 
into /etc/init.d/mydaemon.

On Red Hat, /etc/init.d is a symlink to /etc/rc.d/init.d, and on Suse, 
/etc/rc.d/init.d is a symlink to /etc/init.d.  (Swift's big-endians and 
little-endians have nothing on the arbitrariness of this.)

Packing with CPack 2.8.7's RPM generator wants to insert /etc/init.d into the 
%files list.  The resulting RPM will install on Suse, but on Red Hat, you get:
  file /etc/init.d from install of myproduct-1-1.x86_64 conflicts with file 
from package chkconfig-1.3.30.2-2.el5.x86_64
Naturally, from the symmetry of the situation, if I put my init script in 
/etc/rc.d/init.d/daemon, I get an RPM that installs on Red Hat but doesn't 
install on Suse.

>From a ton of googling, consensus seems to be that for directories that you 
>"know" are on the target system, you don't have to list them in the %files 
>list.  I'm confident that /etc/init.d is in this category.  This is where my 
>subject line comes in:

How do I prevent /etc/init.d from appearing in the %files list, when I have a 
file /etc/init.d/mydaemon that has to be packaged?

The new CPACK_RPM_USER_FILELIST feature from CPack 2.8.7 *almost* works...
  SET(CPACK_RPM_daemoncomponent_USER_FILELIST "/etc/init.d")
...only it gets added back in a different spot.  Darn.  I'd like to be able to 
say something like
  SET(CPACK_RPM_daemoncomponent_USER_FILELIST "%ignore /etc/init.d")
but I haven't found the right magic to use instead of "%ignore".  If there 
indeed is any magic.

I've read the CPackRPM.cmake source and I can see how I can hack it to fix my 
immediate problem, but I'm not keen on hacks.  If there's a Proper Way to do 
what I want then that's what I'll do.

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to