#69 lensfun rpm tries to create dierctories owned by the filesystem rpm

[Herald van der Breggen]

I just cloned the git repo and followed the instructions to create an rpm. This worked right out of the box. Great!

However, when tryong to install I got these error messages:
Uitvoeren transactiecontrole
Transactiecontrole ok.
Uitvoeren transactietest
Fout: Transaction check error:
file /usr/local from install of lensfun-0.3.2.0-1.x86_64 conflicts with file from package filesystem-3.2-37.fc24.x86_64
file /usr/local/bin from install of lensfun-0.3.2.0-1.x86_64 conflicts with file from package filesystem-3.2-37.fc24.x86_64
file /usr/local/include from install of lensfun-0.3.2.0-1.x86_64 conflicts with file from package filesystem-3.2-37.fc24.x86_64
file /usr/local/lib from install of lensfun-0.3.2.0-1.x86_64 conflicts with file from package filesystem-3.2-37.fc24.x86_64
file /usr/local/lib64 from install of lensfun-0.3.2.0-1.x86_64 conflicts with file from package filesystem-3.2-37.fc24.x86_64
file /usr/local/share from install of lensfun-0.3.2.0-1.x86_64 conflicts with file from package filesystem-3.2-37.fc24.x86_64

So maybe it should not try to create these directories, just copy the files...

[Torsten Bronger]

Is this a bug in Lensfun's source code or its documentation? If you, please point me to the file that causes the problem.

[Herald van der Breggen]

[herald@xps13 cmake_build]$ rpm -qlp lensfun-0.3.2.0-Linux.rpm
/usr/local
/usr/local/bin
...

So these directories are specified as "belonging" to the lensfun package.

However, these directories belong to the filesystem package:

[herald@xps13 cmake_build]$ rpm -qf /usr/local
filesystem-3.2-37.fc24.x86_64

So it is a packaging problem. The directories mentioned should not be in the %files section of the spec-file

[Torsten Bronger]

Your observations are certainly valueable. But I just wonder whether we, the Lensfun developers, can do something about it. Maybe it must be handled downstream by the package maintainers (which don't belong to the Lensfun team).

[Herald van der Breggen]

I see. I'll try to find some time to take a closer look so that I can suggest a patch.

[Herald van der Breggen]

OK, it is a know problem (e.g. https://stackoverflow.com/questions/24983181/cpack-generates-rpms-with-files-entries-that-conflict-with-the-rpm-spec-how-to) The problem can be avoided by passing an extra parameter to cmake, together with a list of directories that should be excluded from the file list of the RPM.

What I did was:
$ cmake -DCPACK_BINARY_RPM:BOOL=ON -DCPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION="/usr/local;/usr/local/bin;/usr/local/include;/usr/local/lib;/usr/local/lib64;/usr/local/share" ../

And that fixed the problem.

So the problem can be fixed by a small change in the documentation. On way to do that is:

diff --git a/README.md b/README.md
index 6f89fa1..d5ba1d7 100644
--- a/README.md
+++ b/README.md
@@ -105,6 +105,11 @@ You can also build packages with cmake:
Add -DCPACK_BINARY_DEB:BOOL=ON or -DCPACK_BINARY_RPM:BOOL=ON to the
command line and then "make package". (But this is not extensively tested.)

• You might als want to add an extra parameter, at least on RedHat systems,
• to avoid conflicts with the filesystem package:
  +
• -DCPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION="/usr/local;/usr/local/bin;/usr/local/include;/usr/local/lib;/usr/local/lib64;/usr/local/share"
  +
  Please note that running cmake again does NOT reset all options to default or
  reconfigure all variables. To restart with a clean configuration delete all files
  in your cmake_build folder.

I hope this helps...

[Herald van der Breggen]

Actually, I have a better fix, because the installation at /usr/local is not ideal, because the python modules are not found at /usr/local by default. So starting lensfun-update-data results in an error message "No module named lensfun". Also, it is more common to install rpms at /usr. This makes the cmake command a bit different:

$ cmake -DCPACK_BINARY_RPM:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION="/usr/lib64/pkgconfig;/usr/lib/python3.5;/usr/lib/python3.5/site-packages" ../

And this results in a rpm that works out of the box.

So I would recommend the following change to the README file:

diff --git a/README.md b/README.md
index 6f89fa1..baea25b 100644
--- a/README.md
+++ b/README.md
@@ -105,6 +105,13 @@ You can also build packages with cmake:
Add -DCPACK_BINARY_DEB:BOOL=ON or -DCPACK_BINARY_RPM:BOOL=ON to the
command line and then "make package". (But this is not extensively tested.)


+       You might want to add two extra parameters, at least on RedHat systems,
+       to avoid conflicts with other packages and also to install at the usual
+       /usr location (so the search paths are right out of the box).
+
+       -DCMAKE_INSTALL_PREFIX:PATH=/usr
+       -DCPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION="/usr/lib64/pkgconfig;/usr/lib/python3.5;/usr/lib/python3.5/site-packages"
+
Please note that running cmake again does NOT reset all options to default or 
reconfigure all variables. To restart with a clean configuration delete all files
in your cmake_build folder.

I hope that helps even more ;-)

[Torsten Bronger]

How can we proceed here? We could just apply the patch (thanks for that) but Python3.5 will be out of date, as any other Python version. Can we add a note to adjust the Python version, or is there a general solution?