MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012608CMakeCPackpublic2011-12-06 05:102012-04-20 15:11
ReporterDaniel Morlock 
Assigned ToEric NOULARD 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformLinuxOSGentooOS Version
Product VersionCMake 2.8.6 
Target VersionCMake 2.8.7Fixed in VersionCMake 2.8.7 
Summary0012608: Unexpected %config file declaration.
DescriptionBy default, cmake assumes all files in CPACK_ABSOLUTE_DESTINATION_FILES and CPACK_ABSOLUTE_DESTINATION_FILES_<COMPONENT> to be %config files. Because of this, all files but those in CPACK_RPM_INSTALL_FILES are declared to be %config files in the RPM specs. I'm not sure whether this is an expected behavior - I think all files should be considered to be normal (non-config) files and the user should be able to define (compoment wise) which files should be assumed to be config files.
Steps To Reproduce
Additional InformationAttached a patch which introduced CPACK_RPM_<COMPONENT>_CONFIG_FILES which allows the user to define a list of files which should be considered as config files. If this variable is set, all other files are assumes to be non-config files.
TagsNo tags attached.
Relationships
related to 0010294closed Eric NOULARD Patch for CPack RPM generator (CPACK_RPM_SPEC_IGNORE_FILES) 
Attached Filespatch cmake-2.8.6-CPackRPM.patch (991) 2011-12-06 05:10
https://public.kitware.com/Bug/file/4136/cmake-2.8.6-CPackRPM.patch
patch cmake-2.8.6-CPackRPM-v2.patch (2,783) 2011-12-06 10:25
https://public.kitware.com/Bug/file/4137/cmake-2.8.6-CPackRPM-v2.patch
Issue History
Date ModifiedUsernameFieldChange
2011-12-06 05:10Daniel MorlockNew Issue
2011-12-06 05:10Daniel MorlockFile Added: cmake-2.8.6-CPackRPM.patch
2011-12-06 05:48Eric NOULARDNote Added: 0027918
2011-12-06 07:54Mika FischerNote Added: 0027919
2011-12-06 08:31Eric NOULARDNote Added: 0027920
2011-12-06 08:49Mika FischerNote Added: 0027921
2011-12-06 08:55Eric NOULARDNote Added: 0027922
2011-12-06 08:58Eric NOULARDNote Added: 0027923
2011-12-06 10:25Daniel MorlockFile Added: cmake-2.8.6-CPackRPM-v2.patch
2011-12-06 10:29Daniel MorlockNote Added: 0027924
2011-12-06 11:12Eric NOULARDNote Added: 0027925
2011-12-06 11:20Daniel MorlockNote Added: 0027926
2011-12-12 17:14Eric NOULARDAssigned To => Eric NOULARD
2011-12-12 17:14Eric NOULARDStatusnew => assigned
2011-12-12 17:15Eric NOULARDNote Added: 0027949
2011-12-12 17:15Eric NOULARDTarget Version => CMake 2.8.7
2011-12-12 17:16Eric NOULARDNote Added: 0027950
2011-12-12 17:16Eric NOULARDStatusassigned => resolved
2011-12-12 17:16Eric NOULARDFixed in Version => CMake 2.8.7
2011-12-12 17:16Eric NOULARDResolutionopen => fixed
2012-03-27 02:26Eric NOULARDNote Added: 0028975
2012-03-27 02:26Eric NOULARDStatusresolved => closed
2012-04-20 15:11Eric NOULARDRelationship addedrelated to 0010294

Notes
(0027918)
Eric NOULARD   
2011-12-06 05:48   
Hi Daniel,

First YES having files in CPACK_ABSOLUTE_DESTINATION_FILES
being considered %config is the expected behavior.

This is a bit "raw" feature but there is no reason to
install files with absolute path unless those are some config files
like /etc/xxxx files.
Usually having absolute installed files is a user mistake
when using the INSTALL(... DESTINATION ...) rules.
But may be you have some counter-example? If you do so please explain it here.

The CPACK_ABSOLUTE_DESTINATION_FILES var is automatically computed
by CPack. It is common to all generators, some generators use
this list other simply don't.
Now this could be refined with some USER set variable like the
one you offered.

In the end however if we let absolute installed files
which are not %config files then the produced RPM will not
be relocatable (see CPACK_PACKAGE_RELOCATABLE and CPACK_RPM_PACKAGE_RELOCATABLE)
which is a desired property of many user.

There are other bugs related to this one, I'll draw the link afterwards.
(0027919)
Mika Fischer   
2011-12-06 07:54   
Hi Eric,

Our use-case is that we want to generate a reasonable RPM package using CMake. We want to install our software in /opt/foobar, but some things must go to other places. For instance the init script, which we don't want to be a config file or .destop files, which need to go to /usr/share/applications.

It's also not the case that everything installed with a relative path should not be a config file. If we wanted to install our configuration file also in /opt/foobar, there would be no way to mark it as a conffile.

In general, I really don't think this can be determined automatically in all cases, so some way for the user to override the default behaviour seems like a good thing.
(0027920)
Eric NOULARD   
2011-12-06 08:31   
Hi Mika,

Yes I do totally agree that guessing files that should be %config
and those that shouldn't is probably impossible in the general case.
I did this in order to ease the automatic build of relocatable package.

Moreover you are right,
offering more control to file/dir list to user is a good idea.

I think that we should offer the user with

  0) let CPack automatically collect the list of file
     and dir with a separation between absolute and relative path
     i.e. as it is today in
     CPACK_ABSOLUTE_DESTINATION_FILES
     CPACK_ABSOLUTE_DESTINATION_FILES_<COMPONENT>
    
then
  1) provide a user controlled VARIABLEs
     (say CPACK_RPM_USER_FILES and CPACK_RPM_<COMPONENT>_USER_FILES)
     which contains user specified file line list
     (with or without %config %doc or anything else)

   Every file/dir found in USER variable will be removed from
CPack automatically built list.

  2) And may be a way to disable automatic processing of CPackRPM
     CPACK_RPM_PACKAGE_NO_AUTOMATIC_FILE_FILTER

As a workaround you can currently do what you want if you use
CPACK_RPM_USER_BINARY_SPECFILE, in this case CPackRPM will not
generate any spec file but it will use the one provided by the user.
(0027921)
Mika Fischer   
2011-12-06 08:49   
Hi Eric,

your proposal sounds very good! It would solve our problem and another problem we have (we want to specify %config(noreplace) for some files).

Daniel will give it a try and post an improved patch.

Your suggested workaround is problematic, because then we would need to manage the list of installed files completely by hand. Because of many optional components in our project this would be a significant additional overhead in our case.
(0027922)
Eric NOULARD   
2011-12-06 08:55   
Ok then,

I will happilyreview your patch.
Note however that I have not so much free time,
In fact I already have many things to do/integrate on my CPack plate.

I may not be able to integrate this before 2.8.7 RC cycle is over,
not mentionning that I'll have to ensure that it is safe to include
in 2.8.7 even if it is ready.

Do not expect to have that in 2.8.7.

That said I'm pretty sure the feature will be very useful to other
so go on.
(0027923)
Eric NOULARD   
2011-12-06 08:58   
Last word,

If you provide a patch, may be you can build it against current git master
and not 2.8.6, that way you'll test the probable next 2.8.7 with your
feature as well.
(0027924)
Daniel Morlock   
2011-12-06 10:29   
We are currently using 2.8.6, so I uploaded a patch for this version. Maybe s.b. could check whether this works also for 2.8.7?
(0027925)
Eric NOULARD   
2011-12-06 11:12   
I'll do the check.
(0027926)
Daniel Morlock   
2011-12-06 11:20   
Using the patch you can specify your own file lines:

list(append CPACK_RPM_USER_FILES "%config /etc/init.d/foobar")
list(append CPACK_RPM_USER_FILES "%config(noreplace) /etc/sysconfig/foobar")
list(append CPACK_RPM_USER_FILES "/etc/non_config_file")

Or equivalent using components:

list(append CPACK_RPM_<component>_USER_FILES "%config /etc/init.d/foobar")
list(append CPACK_RPM_<component>_USER_FILES "%config(noreplace) /etc/sysconfig/foobar")
list(append CPACK_RPM_<component>_USER_FILES "/etc/non_config_file")
(0027949)
Eric NOULARD   
2011-12-12 17:15   
May be scheduled for next 2.8.7rc the added behavior should not
affect those not using it.
(0027950)
Eric NOULARD   
2011-12-12 17:16   
Just committed the change to next:
Fetching upstream next
Merge topic 'CPackRPM-0012608-UserSpecificFileControl' into next

121c295 CPackRPM fix 0012608 and unoticed related bug
(0028975)
Eric NOULARD   
2012-03-27 02:26   
Was included in 2.8.7