(0027918)
Eric NOULARD (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (developer)
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 (developer)
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 (reporter)
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 (developer)
2011-12-06 11:12

I'll do the check.

(0027926)
Daniel Morlock (reporter)
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 (developer)
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 (developer)
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 (developer)
2012-03-27 02:26

Was included in 2.8.7

Issue History
Date Modified	Username	Field	Change
2011-12-06 05:10	Daniel Morlock	New Issue
2011-12-06 05:10	Daniel Morlock	File Added: cmake-2.8.6-CPackRPM.patch
2011-12-06 05:48	Eric NOULARD	Note Added: 0027918
2011-12-06 07:54	Mika Fischer	Note Added: 0027919
2011-12-06 08:31	Eric NOULARD	Note Added: 0027920
2011-12-06 08:49	Mika Fischer	Note Added: 0027921
2011-12-06 08:55	Eric NOULARD	Note Added: 0027922
2011-12-06 08:58	Eric NOULARD	Note Added: 0027923
2011-12-06 10:25	Daniel Morlock	File Added: cmake-2.8.6-CPackRPM-v2.patch
2011-12-06 10:29	Daniel Morlock	Note Added: 0027924
2011-12-06 11:12	Eric NOULARD	Note Added: 0027925
2011-12-06 11:20	Daniel Morlock	Note Added: 0027926
2011-12-12 17:14	Eric NOULARD	Assigned To	=> Eric NOULARD
2011-12-12 17:14	Eric NOULARD	Status	new => assigned
2011-12-12 17:15	Eric NOULARD	Note Added: 0027949
2011-12-12 17:15	Eric NOULARD	Target Version	=> CMake 2.8.7
2011-12-12 17:16	Eric NOULARD	Note Added: 0027950
2011-12-12 17:16	Eric NOULARD	Status	assigned => resolved
2011-12-12 17:16	Eric NOULARD	Fixed in Version	=> CMake 2.8.7
2011-12-12 17:16	Eric NOULARD	Resolution	open => fixed
2012-03-27 02:26	Eric NOULARD	Note Added: 0028975
2012-03-27 02:26	Eric NOULARD	Status	resolved => closed
2012-04-20 15:11	Eric NOULARD	Relationship added	related to 0010294

Notes
(0027918) Eric NOULARD (developer) 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 (reporter) 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 (developer) 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 (reporter) 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 (developer) 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 (developer) 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 (reporter) 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 (developer) 2011-12-06 11:12	I'll do the check.

(0027926) Daniel Morlock (reporter) 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 (developer) 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 (developer) 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 (developer) 2012-03-27 02:26	Was included in 2.8.7