MantisBT - CMake
View Issue Details
0012864CMakeCPackpublic2012-01-08 22:442016-06-10 14:31
Deborah Pickett 
Eric NOULARD 
lowfeatureN/A
closedmoved 
Linux
CMake 2.8.7 
CMake 2.8.12 
0012864: CPackRPM additional variable CPACK_RPM_FILTER_FILELIST to remove well-known directories from %files list
As discussed in 0012305, including well-known directories in an RPM .spec %files list can lead to portability problems.

Example:

%files
/etc
/etc/init.d
/etc/init.d/mydaemon

The above innocuous snippet will lead to this unhelpful error when installing on Red Hat (but not on Suse):

file /etc/init.d from install of mypackage-1.x86_64 conflicts with file from package chkconfig-1.3.30.2-2.el5.x86_64

Portable RPMs need to omit "well-known" directories which are certain to be installed on the destination system, like /usr, /etc, /etc/init.d, /dev. This is even more important when the directory is a symbolic link (like /etc/init.d) or a special filesystem (like /dev).

Feature request: define a variable CPACK_RPM_FILTER_FILELIST which contains a list of absolute paths that are to be suppressed from the %files list. By default it should contain "/usr";"/usr/lib";"/etc";"/etc/init.d";"/lib" (negotiable). Also allow user to define additional files/directories in variable CPACK_RPM_FILTER_USER_FILELIST, which are treated similarly.
Probably depends on 0012863
No tags attached.
related to 0012305closed Eric NOULARD RPM should include directories 
has duplicate 0013609closed Eric NOULARD RPM generator wrongly add parents directories to the package 
has duplicate 0013860closed Eric NOULARD RPMs created by CPack don't install on Fedora 18 
related to 0012863closed Eric NOULARD CPackRPM reports "warning: File listed twice" because it recurses directories in %files 
patch CPackRPM.patch (2,754) 2013-01-18 14:05
https://public.kitware.com/Bug/file/4618/CPackRPM.patch
Issue History
2012-01-08 22:44Deborah PickettNew Issue
2012-01-13 14:50Eric NOULARDRelationship addedrelated to 0012863
2012-08-11 21:35David ColeStatusnew => backlog
2012-08-11 21:35David ColeNote Added: 0030423
2012-09-18 12:43James JuranNote Added: 0031047
2012-09-18 13:31Eric NOULARDRelationship addedrelated to 0012305
2012-09-18 13:34Eric NOULARDNote Added: 0031049
2012-09-18 13:38James JuranNote Added: 0031050
2012-09-19 09:41James JuranNote Added: 0031058
2012-10-26 10:16Eric NOULARDRelationship addedhas duplicate 0013609
2013-01-17 18:36Orion PoplawskiNote Added: 0032117
2013-01-18 00:54Eric NOULARDNote Added: 0032119
2013-01-18 10:37Orion PoplawskiNote Added: 0032122
2013-01-18 14:05Jean-Eudes OnfrayNote Added: 0032124
2013-01-18 14:05Jean-Eudes OnfrayFile Added: CPackRPM.patch
2013-01-20 05:51Eric NOULARDRelationship addedhas duplicate 0013860
2013-04-05 07:09Eric NOULARDNote Added: 0032758
2013-04-05 07:09Eric NOULARDAssigned To => Eric NOULARD
2013-04-05 07:09Eric NOULARDStatusbacklog => assigned
2013-04-05 07:10Eric NOULARDNote Added: 0032759
2013-04-05 07:10Eric NOULARDStatusassigned => feedback
2013-04-06 18:54Orion PoplawskiNote Added: 0032773
2013-05-18 22:27Orion PoplawskiNote Added: 0033095
2013-05-20 09:48Eric NOULARDNote Added: 0033102
2013-05-20 09:48Eric NOULARDOS => Linux
2013-05-20 09:48Eric NOULARDTarget Version => CMake 2.8.12
2013-11-05 22:18Orion PoplawskiNote Added: 0034402
2013-11-07 02:51Eric NOULARDNote Added: 0034406
2016-06-10 14:28Kitware RobotNote Added: 0041959
2016-06-10 14:28Kitware RobotStatusfeedback => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0030423)
David Cole   
2012-08-11 21:35   
Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0031047)
James Juran   
2012-09-18 12:43   
I just want to add my two cents that this would be a useful feature. I spent several hours trying to figure out why my RPM is including /usr and /usr/bin in addition to /usr/bin/myprog.

For others who might be facing this problem, there is a workaround described at http://cmake.3232098.n2.nabble.com/CPack-2-8-7-RPM-hiding-etc-init-d-from-files-list-td7157511.html [^] .

Could someone with the appropriate permissions add a relationship to 12305? That would help viewers of that bug find this one.
(0031049)
Eric NOULARD   
2012-09-18 13:34   
Hi James,

I did add the relationship to 0012305.
I know this would be a useful feature, but time is scarce :-]
May be you would be able to try a patch, I'll happily review it.
(0031050)
James Juran   
2012-09-18 13:38   
Thank you Eric, I appreciate you spending your time on this. I have the hack you came up with nearly working on the package we're using as a proof-of-concept for cmake. If we decide to move other things to cmake, I may look into making this fix so I don't have to replicate this hack for each of our packages. I won't be able to do it immediately though for the same time scarcity reasons.
(0031058)
James Juran   
2012-09-19 09:41   
In thinking about this a little bit, I think directories supplied by the "filesystem" RPM on Red Hat-based distributions should not be included in generated RPMs by default. Unfortunately that is 14512 directories on CentOS 6; far too many to explicitly include in CMake. If you are building natively CMake can run "rpm -qf" on the directory in question and see if it is owned by filesystem, but what if you are cross-compiling?

Also, do non-Red Hat distributions have a "filesystem" package that serves an equivalent purpose?
(0032117)
Orion Poplawski   
2013-01-17 18:36   
While it is "convenient" to not have to specify the files and directories owned by the rpm when using cmake, I really think that that is the only sensible way forward. That is what is done in the rpm .spec files when creating them by hand.
(0032119)
Eric NOULARD   
2013-01-18 00:54   
Hi Orion,

Could you elaborate what you mean by "only sensible way forward. That is what is done in the rpm .spec files when creating them by hand"

Do you mean that the user should specify the list himself and keep CPackRPM
away from building any automatic list?

This can already be partially done using:
CPACK_RPM_USER_FILELIST
CPACK_RPM_<COMPONENT>_USER_FILELIST

but there is currently no way to disable generated file list,
the addition of this kind of toggle would be really simple
but is this what you mean?
(0032122)
Orion Poplawski   
2013-01-18 10:37   
Yes, this is what I mean. For example, this is from the cmake rpm that I maintain in Fedora:

%files
%config(noreplace) %{_sysconfdir}/rpm/macros.cmake
%{_docdir}/%{name}-%{version}/
%if %{with gui}
%exclude %{_docdir}/%{name}-%{version}/cmake-gui.*
%endif
%{_bindir}/ccmake
%{_bindir}/cmake
%{_bindir}/cpack
%{_bindir}/ctest
%{_datadir}/aclocal/cmake.m4
%{_datadir}/%{name}/
%{_mandir}/man1/ccmake.1.gz
%{_mandir}/man1/cmake.1.gz
%{_mandir}/man1/cmakecommands.1.gz
%{_mandir}/man1/cmakecompat.1.gz
%{_mandir}/man1/cmakemodules.1.gz
%{_mandir}/man1/cmakepolicies.1.gz
%{_mandir}/man1/cmakeprops.1.gz
%{_mandir}/man1/cmakevars.1.gz
%{_mandir}/man1/cpack.1.gz
%{_mandir}/man1/ctest.1.gz
%{_emacs_sitelispdir}/%{name}
%{_libdir}/%{name}/

The specific files and directories that the cmake rpm should own are listed. But not "parent" directories like /usr/bin, /usr/share/man/man1, etc. To do so is expressly forbidden by the packaging rules precisely because of issues like those being raised here. Note that many people use wildcards (%{_bindir}/*), but I dislike them.

So yeah, a CMAKE_RPM_NO_AUTO_FILELIST or some such seems like a workable and backward compatible way forward.
(0032124)
Jean-Eudes Onfray   
2013-01-18 14:05   
Hi all,

Orion, I like your idea. Here's a patch to implement this.

I added two variables CPACK_RPM_NO_AUTO_FILELIST and CPACK_RPM_USER_FILES
the first is described in Orion's post above.
I created the latter (instead of using CPACK_RPM_USER_FILELIST for example) because you may need to use special rpm macro in it (%doc or %dir for example) and if I used CPACK_RPM_USER_FILELIST it would be broken by CPackRPM internal handling (double quote added, space split...)

Now I have to face just another problem: this doesn't handle correctly i18n files (no way to use macro such as find_lang).

Please comment.
(0032758)
Eric NOULARD   
2013-04-05 07:09   
Orion,
Jean-Eudes,

I did provided a fix for 0013609 which partially solve this current isuse.
I did merged-in this solution first (and not the patch proposal from Jean-Eudes)
because it is more user-friendly.

Jean-Eudes, I would be glad to incorporate your proposal,
i.e. avoid the automatic generation of filelist alltogether,
as well since it gives the user more control.

However I would rather use only one var
CPACK_RPM_USER_FILES_SECTION

if this var is set then it disable the automatic file list generation
and it should contain the whole file section that will be put "as-is"
into the spec file.

We may even offer a second variable:
CPACK_RPM_USER_FILES_SECTION_FILE which would the name of a file
whose content is the file section.
We will then basically to a
file(READ ${CPACK_RPM_USER_FILES_SECTION_FILE} CPACK_RPM_USER_FILES_SECTION)
and proceed.

Would you be willing to try a patch for that?
If you do please do not forget to add documentation for the new
variable(s).

That way
cpack --help-variable CPACK_RPM_USER_FILES_SECTION

will work as expected.
See example at the top of CPackRPM.cmake file.
(0032759)
Eric NOULARD   
2013-04-05 07:10   
Waiting for feedback from Orion and Jean-Eudes
(0032773)
Orion Poplawski   
2013-04-06 18:54   
Since I don't build rpms with CPack, I'm probably not the best person to comment. But CPACK_RPM_USER_FILES_SECTION that disables auto file list generation seems like a reasonable solution.
(0033095)
Orion Poplawski   
2013-05-18 22:27   
I don't suppose this made it into 2.8.11?
(0033102)
Eric NOULARD   
2013-05-20 09:48   
You are right. I was too late in the RC process.
I'll ensure this is merge in for 2.8.12.
(0034402)
Orion Poplawski   
2013-11-05 22:18   
Did this make it into 2.8.12?
(0034406)
Eric NOULARD   
2013-11-07 02:51   
Jean-Eudes patch wasn't merge in 2.8.12,
however from 0013609 fix you now have
CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST

which may be used to define a list of path to be excluded from
"CPack RPM automatic handling machinery"

the default value is:
"/etc /etc/init.d /usr /usr/share /usr/share/doc /usr/bin /usr/lib /usr/lib64 /usr/include"

user may overwrite it with its own set of paths.
(0041959)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.