MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011059CMakeCPackpublic2010-07-29 06:512010-12-15 14:21
ReporterOlaf van der Spek 
Assigned ToEric NOULARD 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in VersionCMake 2.8.4 
Summary0011059: [Deb] Don't require CPACK_PACKAGE_CONTACT
DescriptionDebian Policy might require a Maintainer header, but IMO CPack is not the right place to enforce this policy. For private packages, this header isn't necessary.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0011050closed Domen Vrankar CPack DEB: default to standard Debian package file names 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-07-29 06:51Olaf van der SpekNew Issue
2010-07-30 07:21Eric NOULARDNote Added: 0021571
2010-07-30 07:24Olaf van der SpekNote Added: 0021572
2010-07-30 07:42Eric NOULARDNote Added: 0021573
2010-07-30 07:42Eric NOULARDRelationship addedrelated to 0011050
2010-07-30 07:48Olaf van der SpekNote Added: 0021574
2010-07-30 08:25Eric NOULARDNote Added: 0021575
2010-07-30 08:27Olaf van der SpekNote Added: 0021576
2010-12-15 11:13David ColeAssigned To => Eric NOULARD
2010-12-15 11:13David ColeStatusnew => assigned
2010-12-15 14:21Eric NOULARDNote Added: 0024184
2010-12-15 14:21Eric NOULARDStatusassigned => closed
2010-12-15 14:21Eric NOULARDResolutionopen => won't fix
2010-12-15 14:21Eric NOULARDFixed in Version => CMake 2.8.4

Notes
(0021571)
Eric NOULARD   
2010-07-30 07:21   
I think indeed it is the role of CPack to help in producing
better quality packages.

What is the problem with providing CPACK_PACKAGE_CONTACT ?
If you don't want to give one then

set(CPACK_PACKAGE_CONTACT "private")

and this will please CPackDeb.
(0021572)
Olaf van der Spek   
2010-07-30 07:24   
Having a contact address in my private packages does not make them higher quality.
So for me it's extra work with no gain.
(0021573)
Eric NOULARD   
2010-07-30 07:42   
You are right Olaf,

The trouble is enhancing your ease of use may lower the quality
of package for others.

May be we can add a global CPACK_PACKAGE_EASY toggle
which would indicate to [all] specific generators
to be more "tolerant" on usually
required fields and provide reasonable default values?

Or may be you have a better solution?

I'll wait opinion for other but being more tolerant and generate
non-conforming packages does not seems a good "general" behavior.

Note that on another bug report 11050
(I'll add a link with this one) you ask for a more
conforming naming scheme :-)
(0021574)
Olaf van der Spek   
2010-07-30 07:48   
What Debian tools actually use this field? I've been using Debian for years but I can't think of any tools that use this field.

> Or may be you have a better solution?

Maybe a warning instead of an error?

> Note that on another bug report

I don't see how that's related.
Having architecture in the name is necessary if you're building for both x86 and x64 or for multiple architectures in general.
(0021575)
Eric NOULARD   
2010-07-30 08:25   
>> Or may be you have a better solution?
> Maybe a warning instead of an error?

OK noted.

>> Note that on another bug report
> I don't see how that's related.
> Having architecture in the name is necessary if you're building for both x86 and x64 or for multiple architectures in general.

Because it's about conformance to Debian standard.
(0021576)
Olaf van der Spek   
2010-07-30 08:27   
> Because it's about conformance to Debian standard.

Having the architecture in the file name is not (just) about conforming to that standard.

Don't forget this one:
What Debian tools actually use this field? I've been using Debian for years but I can't think of any tools that use this field.
(0024184)
Eric NOULARD   
2010-12-15 14:21   
Closing without fixing because.
CMake should makes it easier to build "Debian package".

The message is clear and the fix easy to implement.