MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013451CMakeModulespublic2012-08-02 12:032013-01-09 10:54
ReporterAndy Piper 
Assigned ToEric NOULARD 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformLinuxOSOS Version
Product VersionCMake 2.8.8 
Target VersionCMake 2.8.10Fixed in VersionCMake 2.8.10 
Summary0013451: RPMs created with CPackRPM.cmake should not include non-empty directories in their contents-list
DescriptionI am building RPM packages using the CPackRPM.cmake module. The RPMs have a default install prefix of "/opt/mycompany" and have been made relocatable like so:

    set(CPACK_PACKAGING_INSTALL_PREFIX "/opt/mycompany")
    set(CPACK_PACKAGE_RELOCATABLE TRUE)

The RPMs are relocatable because they are being installed into custom locations (using the --prefix option) by non-root users who have private RPM databases (see section 4 of http://www.nordugrid.org/documents/rpm_for_everybody.html [^]). This setup will allow us to install different versions of our components for development and maintenance work on a single machine, as required.

When attempting to install our RPMs to custom locations as a non-root user using a command like this:

    rpm -ivh --prefix=/home/andy/workspace/myproject/contrib \
        --dbpath=/home/andy/workspace/myproject/contrib/rpmdb \
        mypackage-1.0.rpm

...the following error was reported:

    error: unpacking of archive failed on file /opt: cpio: chmod failed - Operation not permitted

But I wasn't installing the RPM to /opt! So I looked at the content-list of the RPM created using CPackRPM.cmake (using "less <rpm-package>"), and saw that it began with:

    /opt
    /opt/mycompany
    /opt/mycompany/lib64
    /opt/mycompany/lib64/libcomponent_one.so
    ...etc...

(FYI, The path "/opt/mycompany" will be replaced by the --prefix option in the "rpm" command above)

I then looked at at the content-list of another relocatable RPM with the same default install prefix, but this package had been created by hand using the "rpmbuild" command and a normal .spec file. The content-list in this RPM began with:

    /opt/mycompany/lib64/libcomponent_two.so
    ...etc...

There were no entries to explicitly create non-empty directories, and this RPM *could* be installed to non-default locations by non-root users (with their fancy private RPM databases). This told me that the entries to create non-empty directories should not be present in the content-list: the RPM package-manager will handle these directories for you.

This led me towards the "EXECUTE_PROCESS(COMMAND find . -type f ...)" call in CPackRPM.cmake which populates the content-list for the RPM being built. This command was searching from the "build root" directory (".") and was including non-empty directories in its output. After changing the search to start at the install-prefix directory ("./${CPACK_PACKAGING_INSTALL_PREFIX}") and ignoring non-empty directories, the RPM-installation issue was resolved.

So the fix is to change the "find" command from this:

    find . -type f -o -type l -o (-type d -a -not -name ".")

to this:

    find ./${CPACK_PACKAGING_INSTALL_PREFIX} -type f -o -type l -o (-type d -a -not -name "." -a -empty)

I have attached a patch with this fix.

Steps To ReproduceBuild any RPM using CPackRPM.cmake and examine the file-list using "less <rpm-package>". The content-list will begin with a series of one or more non-empty directories, when it should begin with the first file (or intentionally empty directory)
Additional InformationFix has been tested on SLES 11.2 and OpenSUSE 12.1
TagsNo tags attached.
Relationships
related to 0012305closed Eric NOULARD RPM should include directories 
Attached Filespatch CPackRPM.cmake.patch (1,285) 2012-08-02 12:03
https://public.kitware.com/Bug/file/4412/CPackRPM.cmake.patch
? CPackRPM.cmake.patch2 (1,276) 2012-08-02 12:09
https://public.kitware.com/Bug/file/4413/CPackRPM.cmake.patch2
patch CPackRPM.cmake.relocatable-prefix.patch (1,926) 2012-08-06 12:47
https://public.kitware.com/Bug/file/4419/CPackRPM.cmake.relocatable-prefix.patch
Issue History
Date ModifiedUsernameFieldChange
2012-08-02 12:03Andy PiperNew Issue
2012-08-02 12:03Andy PiperFile Added: CPackRPM.cmake.patch
2012-08-02 12:08Andy PiperNote Added: 0030158
2012-08-02 12:09Andy PiperFile Added: CPackRPM.cmake.patch2
2012-08-02 12:22Eric NOULARDAssigned To => Eric NOULARD
2012-08-02 12:22Eric NOULARDStatusnew => assigned
2012-08-03 05:01Eric NOULARDRelationship addedrelated to 0012305
2012-08-03 05:09Eric NOULARDNote Added: 0030161
2012-08-06 05:42Andy PiperNote Added: 0030171
2012-08-06 08:01Eric NOULARDNote Added: 0030172
2012-08-06 08:15Andy PiperNote Added: 0030173
2012-08-06 08:33Eric NOULARDNote Added: 0030174
2012-08-06 12:47Andy PiperFile Added: CPackRPM.cmake.relocatable-prefix.patch
2012-08-06 12:48Andy PiperNote Added: 0030176
2012-08-07 03:42Eric NOULARDNote Added: 0030180
2012-08-07 04:49Andy PiperNote Added: 0030181
2012-08-07 13:21Eric NOULARDPlatform => Linux
2012-08-07 13:21Eric NOULARDTarget Version => CMake 2.8.10
2012-08-07 13:21Eric NOULARDNote Added: 0030183
2012-08-07 13:21Eric NOULARDStatusassigned => resolved
2012-08-07 13:21Eric NOULARDFixed in Version => CMake 2.8.10
2012-08-07 13:21Eric NOULARDResolutionopen => fixed
2013-01-09 10:54Robert MaynardNote Added: 0032010
2013-01-09 10:54Robert MaynardStatusresolved => closed

Notes
(0030158)
Andy Piper   
2012-08-02 12:08   
Here's a version of the patch file that doesn't need to have the filenames modified before it can be applied.
(0030161)
Eric NOULARD   
2012-08-03 05:09   
Hi Andy,

You analysis seems OK, but using your method you may miss
ABSOLUTE install path (like /etc/myconf.blah).
Those files are [automatically] flagged "%config" by CPackRPM.

When files are installed to absolute location (like /etc) this does
not prevent the RPM to be relocatable but an absolute-installed file
should be kept where it is even though the RPM is relocated.

You are not in this use-case obviously but I shall whether if your
patch could break this particular use case.

I'll have a look to the latest patch in a couple of day.

I did add the relation to "CPackRPM directory handling" related bugs
for reference.
(0030171)
Andy Piper   
2012-08-06 05:42   
Hi Eric,

You're correct, I didn't consider the "abolute install path" use-case.

It seems to me that the requirements to meet the "absolute-path" and "relocatable-package" use-cases are:

1) If an RPM is relocatable, the contents-list entries which would create the "install-prefix" directory-path should be omitted (This fixes the bug I described in my original post for this ticket)

2) All other directories should be explicitly listed in the RPM's contents-list, as before.

DO you agree with this
(0030172)
Eric NOULARD   
2012-08-06 08:01   
I do agree.

However, concerning 1), "directory-path should be omitted"
From various comments in "RPM directory handling" related bugs
I think that we should keep the %dir entries below the prefix,
even if some of them are empty.

i.e. if prefix is /opt/mycompany then

%dir /opt/mycompany
%dir /opt/mycompany/subdir

should be kept but:

%dir /opt should be dropped.

empty vs non empty directory is not an issue, I think
we could perfectly install empty dirs as soon as they
are subdirs of the prefix. (or they are installed using absolute path).

Why wouldn't install empty dirs?
(0030173)
Andy Piper   
2012-08-06 08:15   
Re: 1) you are correct: an entry with the full path of the install-prefix dir should be included in the contents-list, but entries to create any of its parent dirs should not be included.

I agree with you about empty vs non-empty dirs. The solution I initially proposed was incorrect: not including entries to create non-empty dirs in the contents-list would result in those dirs not being removed when the RPM was uninstalled (as stated in the related "RPM should include directories" bug)
(0030174)
Eric NOULARD   
2012-08-06 08:33   
Ok then I think we reach a consensus on what we should do.

Would you be willing to update your patch to take those "constraint"
into account?
(0030176)
Andy Piper   
2012-08-06 12:48   
An updated patch has been uploaded as "CPackRPM.cmake.relocatable-prefix.patch"
(0030180)
Eric NOULARD   
2012-08-07 03:42   
Hi Andy,

Just reviewed your latest patch.
It's fine, I'll be merging it to next.
I made almost no change (besides tab/whitespace fix) so I'm willing to
grant you authorship of this fix (Signed-Off by me).

If you are ok with that, then could you send me the e-mail I shall use for that
(I need git commit "author line": "Andy Piper <author@example.com>").
If you don't want that I'll take authorship and grant you the fix in the
commit log (using only your name, no e-mail).

Tell me what you want.
(0030181)
Andy Piper   
2012-08-07 04:49   
Hi Eric,

You can use the email address "andy.piper [AT] kaspersky [DOT] com"

Glad I could help :-)
(0030183)
Eric NOULARD   
2012-08-07 13:21   
Fetching upstream next
Merge topic 'CPackRPM-fixRelocatablePrefix' into next

822c1ea Do not include directories which are part of the package install prefix.
(0032010)
Robert Maynard   
2013-01-09 10:54   
Closing resolved issues that have not been updated in more than 4 months.