|
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
|
|
|
|
|
(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. |
|
CPackRPM.patch (2,754) 2013-01-18 14:05