Re: [CMake] CPack 2.8.7 RPM: hiding /etc/init.d from %files list
Hi Eric, On 06/01/2012, at 7:36 PM, Eric Noulard wrote: 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 [...] You are welcome to file a bug report on that. I will, but I think I found an underlying bug too... read on. I think there is an unexpected [nasty] workaround... [...] This should work. At least it works on my small test here. Please tell us if it works for you. Almost. The RPM compiles with the %ignore'd comment (lovely dirty hack, by the way). But the resulting RPM still has the offending directory: $ rpm -q --filesbypkg -p mypackage.rpm mypackage /etc mypackage /etc/init.d mypackage /etc/init.d/mydaemon [...] Hand-editing the .spec file and completely removing the %ignore line, and it's still being included. I think I found out why. When I pack verbosely, I get these warnings from rpmbuild: warning: File listed twice: /etc/init.d/mydaemon warning: File listed twice: /etc/sysconfig warning: File listed twice: /etc/sysconfig/autodesk warning: File listed twice: /etc/sysconfig/autodesk warning: File listed twice: /etc/sysconfig/autodesk/mydaemon warning: File listed twice: /etc/sysconfig/autodesk/mydaemon warning: File listed twice: /etc/sysconfig/autodesk/mydaemon [...] What's happening is that CPack is putting directories in the %files list (as it should) but it isn't tagging them with the %dir directive, so rpmbuild is doing a little mini find . -print on each line in %files, and ends up re-including /etc/init.d when it processes /etc. About the %dir directive: http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-DIR-DIRECTIVE I confirmed that by %ignore-ing /etc too: SET(CPACK_RPM_jobmanager_USER_FILELIST %ignore /etc %ignore /etc/init.d) (%dir would have worked for /etc too) and now the RPM correctly has only mydaemon and not its ancestors: $ rpm -q --filesbypkg -p /tmp/mypackage.rpm mypackage /etc/init.d/mydaemon NOW the workaround succeeds. So here's my assertion: CPackRPM should be explicitly marking directories with %dir in the %files list, to prevent rpmbuild from recursively including each directory's descendants implicitly. That's a pretty big change in behaviour, though. What do other users of CPackRPM think? Perhaps it's never actually come up because we haven't had CPACK_RPM_USER_FILELIST for long enough for anyone to notice. Ok with, but on my side I do happily review clean patches :-] I'll file a bug report for the %dir File listed twice issue as well as a placeholder for your suggested CPACK_RPM_FILTER_FILELIST variable. Then I'll get to work on some patches. Thanks for the hack. I've now got a workaround until 2.8.8. :) -- 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
Re: [CMake] CPack 2.8.7 RPM: hiding /etc/init.d from %files list
2012/1/9 Eric Noulard eric.noul...@gmail.com: 2012/1/9 Deborah Pickett deborah.pick...@autodesk.com: Hi Deborah, So go ahead for the bug report File listed twice Just seen that you have already filed the bug reports, thanks. Putting their refs here for others: http://www.cmake.org/Bug/view.php?id=12863 http://www.cmake.org/Bug/view.php?id=12864 -- 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
Re: [CMake] CPack 2.8.7 RPM: hiding /etc/init.d from %files list
2012/1/6 Deborah Pickett deborah.pick...@autodesk.com: 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
[CMake] CPack 2.8.7 RPM: hiding /etc/init.d from %files list
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
