View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0012864CMakeCPackpublic2012-01-08 22:442016-06-10 14:31
ReporterDeborah Pickett 
Assigned ToEric NOULARD 
PlatformOSLinuxOS Version
Product VersionCMake 2.8.7 
Target VersionCMake 2.8.12Fixed in Version 
Summary0012864: CPackRPM additional variable CPACK_RPM_FILTER_FILELIST to remove well-known directories from %files list
DescriptionAs discussed in 0012305, including well-known directories in an RPM .spec %files list can lead to portability problems.



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-

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.
Additional InformationProbably depends on 0012863
TagsNo tags attached.
Attached Filespatch file icon CPackRPM.patch [^] (2,754 bytes) 2013-01-18 14:05 [Show Content]

related to 0012305closedEric NOULARD RPM should include directories 
has duplicate 0013609closedEric NOULARD RPM generator wrongly add parents directories to the package 
has duplicate 0013860closedEric NOULARD RPMs created by CPack don't install on Fedora 18 
related to 0012863closedEric NOULARD CPackRPM reports "warning: File listed twice" because it recurses directories in %files 

David Cole (manager)
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: [^]

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.
James Juran (reporter)
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 [^] .

Could someone with the appropriate permissions add a relationship to 12305? That would help viewers of that bug find this one.
Eric NOULARD (developer)
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.
James Juran (reporter)
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.
James Juran (reporter)
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?
Orion Poplawski (reporter)
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.
Eric NOULARD (developer)
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:

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?
Orion Poplawski (reporter)
2013-01-18 10:37

Yes, this is what I mean. For example, this is from the cmake rpm that I maintain in Fedora:

%config(noreplace) %{_sysconfdir}/rpm/macros.cmake
%if %{with gui}
%exclude %{_docdir}/%{name}-%{version}/cmake-gui.*

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.
Jean-Eudes Onfray (reporter)
2013-01-18 14:05

Hi all,

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

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.
Eric NOULARD (developer)
2013-04-05 07:09


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

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

That way
cpack --help-variable CPACK_RPM_USER_FILES_SECTION

will work as expected.
See example at the top of CPackRPM.cmake file.
Eric NOULARD (developer)
2013-04-05 07:10

Waiting for feedback from Orion and Jean-Eudes
Orion Poplawski (reporter)
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.
Orion Poplawski (reporter)
2013-05-18 22:27

I don't suppose this made it into 2.8.11?
Eric NOULARD (developer)
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.
Orion Poplawski (reporter)
2013-11-05 22:18

Did this make it into 2.8.12?
Eric NOULARD (developer)
2013-11-07 02:51

Jean-Eudes patch wasn't merge in 2.8.12,
however from 0013609 fix you now have

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.
Kitware Robot (administrator)
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.

 Issue History
Date Modified Username Field Change
2012-01-08 22:44 Deborah Pickett New Issue
2012-01-13 14:50 Eric NOULARD Relationship added related to 0012863
2012-08-11 21:35 David Cole Status new => backlog
2012-08-11 21:35 David Cole Note Added: 0030423
2012-09-18 12:43 James Juran Note Added: 0031047
2012-09-18 13:31 Eric NOULARD Relationship added related to 0012305
2012-09-18 13:34 Eric NOULARD Note Added: 0031049
2012-09-18 13:38 James Juran Note Added: 0031050
2012-09-19 09:41 James Juran Note Added: 0031058
2012-10-26 10:16 Eric NOULARD Relationship added has duplicate 0013609
2013-01-17 18:36 Orion Poplawski Note Added: 0032117
2013-01-18 00:54 Eric NOULARD Note Added: 0032119
2013-01-18 10:37 Orion Poplawski Note Added: 0032122
2013-01-18 14:05 Jean-Eudes Onfray Note Added: 0032124
2013-01-18 14:05 Jean-Eudes Onfray File Added: CPackRPM.patch
2013-01-20 05:51 Eric NOULARD Relationship added has duplicate 0013860
2013-04-05 07:09 Eric NOULARD Note Added: 0032758
2013-04-05 07:09 Eric NOULARD Assigned To => Eric NOULARD
2013-04-05 07:09 Eric NOULARD Status backlog => assigned
2013-04-05 07:10 Eric NOULARD Note Added: 0032759
2013-04-05 07:10 Eric NOULARD Status assigned => feedback
2013-04-06 18:54 Orion Poplawski Note Added: 0032773
2013-05-18 22:27 Orion Poplawski Note Added: 0033095
2013-05-20 09:48 Eric NOULARD Note Added: 0033102
2013-05-20 09:48 Eric NOULARD OS => Linux
2013-05-20 09:48 Eric NOULARD Target Version => CMake 2.8.12
2013-11-05 22:18 Orion Poplawski Note Added: 0034402
2013-11-07 02:51 Eric NOULARD Note Added: 0034406
2016-06-10 14:28 Kitware Robot Note Added: 0041959
2016-06-10 14:28 Kitware Robot Status feedback => resolved
2016-06-10 14:28 Kitware Robot Resolution open => moved
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team