|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012574||CMake||CPack||public||2011-11-11 03:13||2016-06-10 14:31|
|Assigned To||Kitware Robot|
|Target Version||Fixed in Version|
|Summary||0012574: package name for the nameless component in DEB should not include the "-unspecified" extension|
|Description||The common package names for an package called myapp would be as follows|
myapp-data - contains mostly architecture independent readonly data required by the application.
myapp-lib - contains libraries used by the application and those which may be used other applications
myapp - Contains the main application and depends on the lib and data components
myapp-dev - contains header files required for development
Currently, the data, lib and dev component packages can be be generated by cpack. However, the myapp package that has no extension cannot be created as cpack autmatically adds the "-unspecified" extension to the package name.
The attached patch ensures that the nameless component is indeed nameless in the finally generated package.
|Tags||No tags attached.|
|Attached Files||0001-Even-through-the-file-name-has-Unpecified-in-it-let-.patch [^] (1,379 bytes) 2011-11-11 03:13 [Show Content]|
Eric NOULARD (developer)
The need is clear,
besides the debian/rpm component naming scheme is obviously not powerful
see http://www.cmake.org/pipermail/cmake/2011-November/047304.html [^]
or related bugs.
So the currentidea is interesting, but the change is not backward compatible
so far. Moreover I would rather make some more powerful modification
that would enable more flexible user-control over naming scheme
(including the present one).
I'll try to gather idea and propose something.
Kishore Jonnalagadda (reporter)
Backward compatible? I.e. there could be deployments that depend on the -unspecified in the package name?
Yes it would be nice to solve the many problems all together but there should a scope of features to achieve even if in a phased manner. So what are the features in the grand scheme of things? I can think of...
1) dependency between components (I think there is a bug report for this...)
2) user provided dependencies per component
3) automatic dependencies per (non binary) component. It would be really cool if the dev component can depend automatically on the various other dev components.
4) per component generated package file name
The 4th might be easy to manage but the others might be fairly involved.
Eric NOULARD (developer)
> I.e. there could be deployments that depend on the -unspecified in the package name?
No I don't think so but the "unspecified" component was created as a sign
of "left over" installed items for which no component name has been specified.
Making it appear as a "default" package makes this indication disappear.
Yes there is several bug report concerning component dependency handling
0011656, 0011944, 0010292 some already contains patches.
The user provided dependencies is already there for RPM but not for DEB.
I think we should handle:
1) clean and flexible (i.e. user controlable) naming scheme then
2) the user-provided deps then,
3) go for automatic deps in a last phase
1) could (?should?) be generic (for all CPack generators)
2) may be generator (DEB, RPM,...) specific
3) will certainly be generator specific
Eric NOULARD (developer)
Have a look at how
CPACK_"+Name+"_USE_DISPLAY_NAME_IN_FILENAME is handled
and look whether if it's possible to authorize "empty" display
name for component (or component groups).
We must be able to distinguish between "empty" and "not defined"
set(CPACK_COMPONENT_Unspecified_DISPLAY_NAME "") could be enough.
Kitware Robot (administrator)
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.
|2011-11-11 03:13||Kishore Jonnalagadda||New Issue|
|2011-11-11 03:13||Kishore Jonnalagadda||File Added: 0001-Even-through-the-file-name-has-Unpecified-in-it-let-.patch|
|2011-11-11 04:29||Eric NOULARD||Note Added: 0027755|
|2011-11-11 04:29||Eric NOULARD||Relationship added||related to 0011050|
|2011-11-11 04:30||Eric NOULARD||Assigned To||=> Eric NOULARD|
|2011-11-11 04:30||Eric NOULARD||Status||new => assigned|
|2011-11-11 13:49||Kishore Jonnalagadda||Note Added: 0027781|
|2011-11-11 14:03||Eric NOULARD||Note Added: 0027783|
|2011-12-12 18:04||Eric NOULARD||Note Added: 0027953|
|2012-02-25 18:03||Eric NOULARD||Relationship added||related to 0012997|
|2015-11-08 13:10||Eric NOULARD||Assigned To||Eric NOULARD =>|
|2016-06-10 14:28||Kitware Robot||Note Added: 0041931|
|2016-06-10 14:28||Kitware Robot||Status||assigned => resolved|
|2016-06-10 14:28||Kitware Robot||Resolution||open => moved|
|2016-06-10 14:28||Kitware Robot||Assigned To||=> Kitware Robot|
|2016-06-10 14:31||Kitware Robot||Status||resolved => closed|
|Copyright © 2000 - 2018 MantisBT Team|