2012/1/6 Deborah Pickett <[email protected]>:
> 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.

This one is really annoying and has growing bug report history:
http://public.kitware.com/Bug/view.php?id=12305
http://public.kitware.com/Bug/view.php?id=9654
http://public.kitware.com/Bug/view.php?id=12542

> 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.

I think you are right for that and we should add a list of "don't"
include directories,
or more generally
We should add

CPACK_RPM_FILTER_FILELIST

which would contains the  file (or directory) names that shouldn't be
included in the RPM.
This should contain sensible default values like:

/usr
/usr/lib
/etc
/etc/init.d
/lib

and be complemented with
CPACK_RPM_FILTER_USER_FILELIST

You are welcome to file a bug report on that.

> 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?

I think there is an unexpected [nasty] workaround...

1) first define a custom RPM spec macro called "ignore" which will
simply comment out
    the rest of the line.
     set(CPACK_RPM_SPEC_MORE_DEFINE "%define ignore \#")

2) use this macro in your USER FILE list:
     set(CPACK_RPM_USER_FILELIST "%ignore /etc/init.d")

This should work. At least it works on my small test here.
Please tell us if it works for you.

You can check the resulting spec file:

CPackRPM: Will use GENERATED spec file: .... blah.spec

and then you can check the resulting spec file:

rpmspec -P blah.spec

will produce the processed spec file
in which /etc/init.d should have been removed from %file list
and %ignore lines simply dropped.


> 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.

Ok with, but on my side I do happily review clean patches :-]

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--

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