CPack RPM: file XXX conflicts with file from package filesystem-yyy...

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

CPack RPM: file XXX conflicts with file from package filesystem-yyy...

Mario Emmenlauer

I'm trying to build an RPM with CPack, and everything seems to work,
but the resulting package can not be installed. I get Transaction check
error:
  file / from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
  file /opt from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
  file /usr/bin from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
  file /usr/share from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
  file /usr from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64

I've read in the CPackRPM source code about how to add excludes and
CPackRPM says that my "Final list of path to OMIT in RPM" would be
/etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications

I can see that the conflicting directories are removed from
CPACK_RPM_INSTALL_FILES. But that does not satisfy rpm :-(

Could someone shed some light? I believe that the problem may be
my install command: I call install only once for the full tree
of files that I'd like to package:
  install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/" USE_SOURCE_PERMISSIONS)

I have a wild guess that this install somehow includes the
directories, and probably it would be better to just call install
on the individual files? I would prefer not to call install on the
individual files because that overrides file permissions for every
file, and I carefully prepared my package upfront to have the
exact permissions for installation.

Any help would be greatly appreciated!

All the best,

    Mario Emmenlauer
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CPack RPM: file XXX conflicts with file from package filesystem-yyy...

Eric Noulard


Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer <[hidden email]> a écri

I'm trying to build an RPM with CPack, and everything seems to work,
but the resulting package can not be installed. I get Transaction check
error:
  file / from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
  file /opt from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
  file /usr/bin from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
  file /usr/share from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
  file /usr from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64

I've read in the CPackRPM source code about how to add excludes and
CPackRPM says that my "Final list of path to OMIT in RPM" would be
/etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications

You can read the doc too:
 

I can see that the conflicting directories are removed from
CPACK_RPM_INSTALL_FILES. But that does not satisfy rpm :-(

Could someone shed some light? I believe that the problem may be
my install command: I call install only once for the full tree
of files that I'd like to package:
  install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/" USE_SOURCE_PERMISSIONS)

Yep this is looking for trouble.
How did you build the "${INSTALL_TMP_ROOT}" in the first place?

Can't you use relative path install DESTINATION ? For all files/target you build?
 
I have a wild guess that this install somehow includes the
directories, and probably it would be better to just call install
on the individual files?

CPack RPM tries its best to avoid shipping directories he does not need to ship, but
RPM requires that any new (non shared) directory should be specified in the spec file,
so CPackRPM tries to "discover that" automatically and make the package relocatable.

Installing a whole directory to an absolute DESTINATION (even "/" in you case) is probably 
giving tough time to CPackRPM.
 
I would prefer not to call install on the
individual files because that overrides file permissions for every
file, and I carefully prepared my package upfront to have the
exact permissions for installation.

How did you "carefully prepared my package upfront" ?
And what do you mean by
"because that overrides file permissions for every file"
 
one more question, could you tell us which version of CPack/CMake you are using?


--
Eric

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CPack RPM: file XXX conflicts with file from package filesystem-yyy...

Mario Emmenlauer

Dear Eric, thanks for the help! Below more:

On 22.11.18 18:20, Eric Noulard wrote:

> Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer <[hidden email] <mailto:[hidden email]>> a écri
>     I'm trying to build an RPM with CPack, and everything seems to work,
>     but the resulting package can not be installed. I get Transaction check
>     error:
>       file / from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /opt from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /usr/bin from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /usr/share from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /usr from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>
>     I've read in the CPackRPM source code about how to add excludes and
>     CPackRPM says that my "Final list of path to OMIT in RPM" would be
>     /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
>
>
> You can read the doc too:
> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST

Haha, done that! I've read everything I could find, including the
docs and the excellent but hard-to-find community wiki at
https://gitlab.kitware.com/cmake/community/wikis/home


>     I can see that the conflicting directories are removed from
>     CPACK_RPM_INSTALL_FILES. But that does not satisfy rpm :-(
>
>     Could someone shed some light? I believe that the problem may be
>     my install command: I call install only once for the full tree
>     of files that I'd like to package:
>       install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/" USE_SOURCE_PERMISSIONS)
>
>
> Yep this is looking for trouble.
> How did you build the "${INSTALL_TMP_ROOT}" in the first place?
>
> Can't you use relative path install DESTINATION ? For all files/target you build?

I'm not sure if I can use a relative path. I want to build a system package
that installs to /opt/<package>/ with symlinks in /usr/bin/ and desktop
files in /usr/share/applications/. Since files go into different paths below
system root (/opt, /usr, maybe /var) I assume I need to install into root?
Maybe I misunderstand?


>     I have a wild guess that this install somehow includes the
>     directories, and probably it would be better to just call install
>     on the individual files?
>
>
> CPack RPM tries its best to avoid shipping directories he does not need to ship, but
> RPM requires that any new (non shared) directory should be specified in the spec file,
> so CPackRPM tries to "discover that" automatically and make the package relocatable.
>
> Installing a whole directory to an absolute DESTINATION (even "/" in you case) is probably 
> giving tough time to CPackRPM.

There is something I don't understand: I can see that CPackRPM removes
several things from CPACK_RPM_INSTALL_FILES, but later rpm complains
about several of the removed items nonetheless. For example /usr/bin.
Does that mean the filtering failed, or does the filter work but (somehow)
the directory still ends up being packaged?


>     I would prefer not to call install on the
>     individual files because that overrides file permissions for every
>     file, and I carefully prepared my package upfront to have the
>     exact permissions for installation.
>
>
> How did you "carefully prepared my package upfront" ?
> And what do you mean by
> "because that overrides file permissions for every file"

Currently I bundle my package in a temporary directory for three reasons:
 - Its easier for me to grasp. I.e. I can nicely inspect the package and
   see what will be bundled before the fact.
 - In the temporary copy, I can override RPATH on binaries and libraries
   without changing them in their actual install location.
 - I prefer file(COPY) over install(FILES) because the former can set
   permissions with complex patterns. I appreciate that file(COPY) allows
   me to set executable permissions on *.so and binaries with a single
   invocation (in a loop over many directories).


> one more question, could you tell us which version of CPack/CMake you are using?

I'm on the latest cmake 3.13 as of now, but I tested 3.12.4 as well.

All the best,

    Mario Emmenlauer
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CPack RPM: file XXX conflicts with file from package filesystem-yyy...

Eric Noulard


Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer <[hidden email]> a écrit :

Dear Eric, thanks for the help! Below more:

On 22.11.18 18:20, Eric Noulard wrote:
> Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer <[hidden email] <mailto:[hidden email]>> a écri
>     I'm trying to build an RPM with CPack, and everything seems to work,
>     but the resulting package can not be installed. I get Transaction check
>     error:
>       file / from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /opt from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /usr/bin from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /usr/share from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>       file /usr from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>
>     I've read in the CPackRPM source code about how to add excludes and
>     CPackRPM says that my "Final list of path to OMIT in RPM" would be
>     /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
>
>
> You can read the doc too:
> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST

Haha, done that! I've read everything I could find, including the
docs and the excellent but hard-to-find community wiki at
https://gitlab.kitware.com/cmake/community/wikis/home

OK then you are up-to-doc then.

>     Could someone shed some light? I believe that the problem may be
>     my install command: I call install only once for the full tree
>     of files that I'd like to package:
>       install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/" USE_SOURCE_PERMISSIONS)
>
> Yep this is looking for trouble.
> How did you build the "${INSTALL_TMP_ROOT}" in the first place?
>
> Can't you use relative path install DESTINATION ? For all files/target you build?

I'm not sure if I can use a relative path. I want to build a system package
that installs to /opt/<package>/ with symlinks in /usr/bin/ and desktop
files in /usr/share/applications/. Since files go into different paths below
system root (/opt, /usr, maybe /var) I assume I need to install into root?
Maybe I misunderstand?

Not really. Usually you install in relative bin/ share/ man/ whatever other subdir you need.
Then you define CPACK_PACKAGING_INSTALL_PREFIX (see https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html)
to set up your "main" install prefix for your package. Every CPack generator has a default **packaging install prefix** (not to be confused with CMAKE_INSTALL_PREFIX).
In your case: 
set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") 
which should even be (AFAIR) the default value for RPM and DEB.

Concerning the symlink in /usr/bin (or other places /usr/share etc...) this usually done using post-install script

the script itself may call standard symlink creation like https://linux.die.net/man/8/update-alternatives

Sometimes you *really* need absolute prefix like when you install in /etc/init...
then for those (generally system) specific file you install them with absolute destination.
CPackRPM is able to handle those as "config" file automatically.

>     I have a wild guess that this install somehow includes the
>     directories, and probably it would be better to just call install
>     on the individual files?
>
> CPack RPM tries its best to avoid shipping directories he does not need to ship, but
> RPM requires that any new (non shared) directory should be specified in the spec file,
> so CPackRPM tries to "discover that" automatically and make the package relocatable.
>
> Installing a whole directory to an absolute DESTINATION (even "/" in you case) is probably 
> giving tough time to CPackRPM.

There is something I don't understand: I can see that CPackRPM removes
several things from CPACK_RPM_INSTALL_FILES, but later rpm complains
about several of the removed items nonetheless. For example /usr/bin.
Does that mean the filtering failed, or does the filter work but (somehow)
the directory still ends up being packaged?

Evil usually hides in details.

Difficult to say without having the actual code and package to look into it.
Is your project public? If so could you provide us with the source?

If not tries to setup a stripped down public project that exhibit the same issue.
 
>     I would prefer not to call install on the
>     individual files because that overrides file permissions for every
>     file, and I carefully prepared my package upfront to have the
>     exact permissions for installation.
>
>
> How did you "carefully prepared my package upfront" ?
> And what do you mean by
> "because that overrides file permissions for every file"

Currently I bundle my package in a temporary directory for three reasons:
 - Its easier for me to grasp. I.e. I can nicely inspect the package and
   see what will be bundled before the fact.

make/ninja DESTDIR=/tmp/testinstall all

may be used equally for that.
 
 - In the temporary copy, I can override RPATH on binaries and libraries
   without changing them in their actual install location.

If you have a "clean" prefix and relative install path for all binaries then you can safely use $ORIGIN 

 
 - I prefer file(COPY) over install(FILES) because the former can set
   permissions with complex patterns. I appreciate that file(COPY) allows
   me to set executable permissions on *.so and binaries with a single
   invocation (in a loop over many directories).

if you install(TARGET ..) any binaries or .so would have the appropriate permissions precisely because cmake
knows what they are and does not consider them as "file" which is the case for install(FILES).
 
> one more question, could you tell us which version of CPack/CMake you are using?

I'm on the latest cmake 3.13 as of now, but I tested 3.12.4 as well.

Then you have all bleeding edge feature with you.

I'm not trying to tell you what to do with your install, I'm just trying what CPack expects.

install(DIRECTORY ...) is a kind of trap-them-all for things that are not installed otherwise, this is usually used for things like
generated documentation and not for "normally built artefact" like executable, libraries etc...


-- 
Eric

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CPack RPM: file XXX conflicts with file from package filesystem-yyy...

Mario Emmenlauer

Dear Eric,

thanks a lot for this help! I think I have the pointers to move forward!
One more detail below:

On 23.11.18 11:36, Eric Noulard wrote:

> Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer <[hidden email] <mailto:[hidden email]>> a écrit :
>     Dear Eric, thanks for the help! Below more:
>
>     On 22.11.18 18:20, Eric Noulard wrote:
>     > Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer <[hidden email] <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>> a écri
>     >     I'm trying to build an RPM with CPack, and everything seems to work,
>     >     but the resulting package can not be installed. I get Transaction check
>     >     error:
>     >       file / from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>     >       file /opt from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>     >       file /usr/bin from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>     >       file /usr/share from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>     >       file /usr from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>     >
>     >     I've read in the CPackRPM source code about how to add excludes and
>     >     CPackRPM says that my "Final list of path to OMIT in RPM" would be
>     >     /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
>     >
>     >
>     > You can read the doc too:
>     > https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST
>
>     Haha, done that! I've read everything I could find, including the
>     docs and the excellent but hard-to-find community wiki at
>     https://gitlab.kitware.com/cmake/community/wikis/home
>
>
> OK then you are up-to-doc then.
>
>     >     Could someone shed some light? I believe that the problem may be
>     >     my install command: I call install only once for the full tree
>     >     of files that I'd like to package:
>     >       install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/" USE_SOURCE_PERMISSIONS)
>     >
>     > Yep this is looking for trouble.
>     > How did you build the "${INSTALL_TMP_ROOT}" in the first place?
>     >
>     > Can't you use relative path install DESTINATION ? For all files/target you build?
>
>     I'm not sure if I can use a relative path. I want to build a system package
>     that installs to /opt/<package>/ with symlinks in /usr/bin/ and desktop
>     files in /usr/share/applications/. Since files go into different paths below
>     system root (/opt, /usr, maybe /var) I assume I need to install into root?
>     Maybe I misunderstand?
>
>
> Not really. Usually you install in relative bin/ share/ man/ whatever other subdir you need.
> Then you define CPACK_PACKAGING_INSTALL_PREFIX (see https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html)
> to set up your "main" install prefix for your package. Every CPack generator has a default **packaging install prefix** (not to be confused with
> CMAKE_INSTALL_PREFIX).
> In your case: 
> set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") 
> which should even be (AFAIR) the default value for RPM and DEB.
>
> Concerning the symlink in /usr/bin (or other places /usr/share etc...) this usually done using post-install script
> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE
>
> the script itself may call standard symlink creation like https://linux.die.net/man/8/update-alternatives

Aha, now I see the recommended approach! Makes perfect sense! So I will
continue to bundle up everything, but try to avoid files outside my
man package directory (for me /opt/${PROJECT_NAME}). Then I will make
the system integration (to /usr/bin, /usr/share, etc) via symlinks
and update-alternatives in post-install scripts. This makes perfect
sense, I'm sorry I did not think of it myself!

All the best,

    Mario



> Sometimes you *really* need absolute prefix like when you install in /etc/init...
> then for those (generally system) specific file you install them with absolute destination.
> CPackRPM is able to handle those as "config" file automatically.
>
>     >     I have a wild guess that this install somehow includes the
>     >     directories, and probably it would be better to just call install
>     >     on the individual files?
>     >
>     > CPack RPM tries its best to avoid shipping directories he does not need to ship, but
>     > RPM requires that any new (non shared) directory should be specified in the spec file,
>     > so CPackRPM tries to "discover that" automatically and make the package relocatable.
>     >
>     > Installing a whole directory to an absolute DESTINATION (even "/" in you case) is probably 
>     > giving tough time to CPackRPM.
>
>     There is something I don't understand: I can see that CPackRPM removes
>     several things from CPACK_RPM_INSTALL_FILES, but later rpm complains
>     about several of the removed items nonetheless. For example /usr/bin.
>     Does that mean the filtering failed, or does the filter work but (somehow)
>     the directory still ends up being packaged?
>
>
> Evil usually hides in details.
>
> Difficult to say without having the actual code and package to look into it.
> Is your project public? If so could you provide us with the source?
>
> If not tries to setup a stripped down public project that exhibit the same issue.
>  
>
>     >     I would prefer not to call install on the
>     >     individual files because that overrides file permissions for every
>     >     file, and I carefully prepared my package upfront to have the
>     >     exact permissions for installation.
>     >
>     >
>     > How did you "carefully prepared my package upfront" ?
>     > And what do you mean by
>     > "because that overrides file permissions for every file"
>
>     Currently I bundle my package in a temporary directory for three reasons:
>      - Its easier for me to grasp. I.e. I can nicely inspect the package and
>        see what will be bundled before the fact.
>
>
> make/ninja DESTDIR=/tmp/testinstall all
>
> may be used equally for that.
>  
>
>      - In the temporary copy, I can override RPATH on binaries and libraries
>        without changing them in their actual install location.
>
>
> If you have a "clean" prefix and relative install path for all binaries then you can safely use $ORIGIN 
> see: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling
>
>  
>
>      - I prefer file(COPY) over install(FILES) because the former can set
>        permissions with complex patterns. I appreciate that file(COPY) allows
>        me to set executable permissions on *.so and binaries with a single
>        invocation (in a loop over many directories).
>
>
> if you install(TARGET ..) any binaries or .so would have the appropriate permissions precisely because cmake
> knows what they are and does not consider them as "file" which is the case for install(FILES).
>  
>
>     > one more question, could you tell us which version of CPack/CMake you are using?
>
>     I'm on the latest cmake 3.13 as of now, but I tested 3.12.4 as well.
>
>
> Then you have all bleeding edge feature with you.
>
> I'm not trying to tell you what to do with your install, I'm just trying what CPack expects.
>
> install(DIRECTORY ...) is a kind of trap-them-all for things that are not installed otherwise, this is usually used for things like
> generated documentation and not for "normally built artefact" like executable, libraries etc...
>
>
> -- 
> Eric

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CPack RPM: file XXX conflicts with file from package filesystem-yyy...

Mario Emmenlauer

Dear Eric,

just to let you know, your suggestion of using a post-install-script
for all system-wide links and files was indeed the solution to a working
RPM package. Now my files are completely encapsulated in /opt/PKGNAME/
and install works fine.

Cheers and Thanks,

   Mario



On 23.11.18 15:37, Mario Emmenlauer wrote:

>
> Dear Eric,
>
> thanks a lot for this help! I think I have the pointers to move forward!
> One more detail below:
>
> On 23.11.18 11:36, Eric Noulard wrote:
>> Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer <[hidden email] <mailto:[hidden email]>> a écrit :
>>     Dear Eric, thanks for the help! Below more:
>>
>>     On 22.11.18 18:20, Eric Noulard wrote:
>>     > Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer <[hidden email] <mailto:[hidden email]> <mailto:[hidden email]
>>     <mailto:[hidden email]>>> a écri
>>     >     I'm trying to build an RPM with CPack, and everything seems to work,
>>     >     but the resulting package can not be installed. I get Transaction check
>>     >     error:
>>     >       file / from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>>     >       file /opt from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>>     >       file /usr/bin from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>>     >       file /usr/share from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>>     >       file /usr from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>>     >
>>     >     I've read in the CPackRPM source code about how to add excludes and
>>     >     CPackRPM says that my "Final list of path to OMIT in RPM" would be
>>     >     /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
>>     >
>>     >
>>     > You can read the doc too:
>>     > https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST
>>
>>     Haha, done that! I've read everything I could find, including the
>>     docs and the excellent but hard-to-find community wiki at
>>     https://gitlab.kitware.com/cmake/community/wikis/home
>>
>>
>> OK then you are up-to-doc then.
>>
>>     >     Could someone shed some light? I believe that the problem may be
>>     >     my install command: I call install only once for the full tree
>>     >     of files that I'd like to package:
>>     >       install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/" USE_SOURCE_PERMISSIONS)
>>     >
>>     > Yep this is looking for trouble.
>>     > How did you build the "${INSTALL_TMP_ROOT}" in the first place?
>>     >
>>     > Can't you use relative path install DESTINATION ? For all files/target you build?
>>
>>     I'm not sure if I can use a relative path. I want to build a system package
>>     that installs to /opt/<package>/ with symlinks in /usr/bin/ and desktop
>>     files in /usr/share/applications/. Since files go into different paths below
>>     system root (/opt, /usr, maybe /var) I assume I need to install into root?
>>     Maybe I misunderstand?
>>
>>
>> Not really. Usually you install in relative bin/ share/ man/ whatever other subdir you need.
>> Then you define CPACK_PACKAGING_INSTALL_PREFIX (see https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html)
>> to set up your "main" install prefix for your package. Every CPack generator has a default **packaging install prefix** (not to be confused with
>> CMAKE_INSTALL_PREFIX).
>> In your case: 
>> set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") 
>> which should even be (AFAIR) the default value for RPM and DEB.
>>
>> Concerning the symlink in /usr/bin (or other places /usr/share etc...) this usually done using post-install script
>> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE
>>
>> the script itself may call standard symlink creation like https://linux.die.net/man/8/update-alternatives
>
> Aha, now I see the recommended approach! Makes perfect sense! So I will
> continue to bundle up everything, but try to avoid files outside my
> man package directory (for me /opt/${PROJECT_NAME}). Then I will make
> the system integration (to /usr/bin, /usr/share, etc) via symlinks
> and update-alternatives in post-install scripts. This makes perfect
> sense, I'm sorry I did not think of it myself!
>
> All the best,
>
>     Mario
>
>
>
>> Sometimes you *really* need absolute prefix like when you install in /etc/init...
>> then for those (generally system) specific file you install them with absolute destination.
>> CPackRPM is able to handle those as "config" file automatically.
>>
>>     >     I have a wild guess that this install somehow includes the
>>     >     directories, and probably it would be better to just call install
>>     >     on the individual files?
>>     >
>>     > CPack RPM tries its best to avoid shipping directories he does not need to ship, but
>>     > RPM requires that any new (non shared) directory should be specified in the spec file,
>>     > so CPackRPM tries to "discover that" automatically and make the package relocatable.
>>     >
>>     > Installing a whole directory to an absolute DESTINATION (even "/" in you case) is probably 
>>     > giving tough time to CPackRPM.
>>
>>     There is something I don't understand: I can see that CPackRPM removes
>>     several things from CPACK_RPM_INSTALL_FILES, but later rpm complains
>>     about several of the removed items nonetheless. For example /usr/bin.
>>     Does that mean the filtering failed, or does the filter work but (somehow)
>>     the directory still ends up being packaged?
>>
>>
>> Evil usually hides in details.
>>
>> Difficult to say without having the actual code and package to look into it.
>> Is your project public? If so could you provide us with the source?
>>
>> If not tries to setup a stripped down public project that exhibit the same issue.
>>  
>>
>>     >     I would prefer not to call install on the
>>     >     individual files because that overrides file permissions for every
>>     >     file, and I carefully prepared my package upfront to have the
>>     >     exact permissions for installation.
>>     >
>>     >
>>     > How did you "carefully prepared my package upfront" ?
>>     > And what do you mean by
>>     > "because that overrides file permissions for every file"
>>
>>     Currently I bundle my package in a temporary directory for three reasons:
>>      - Its easier for me to grasp. I.e. I can nicely inspect the package and
>>        see what will be bundled before the fact.
>>
>>
>> make/ninja DESTDIR=/tmp/testinstall all
>>
>> may be used equally for that.
>>  
>>
>>      - In the temporary copy, I can override RPATH on binaries and libraries
>>        without changing them in their actual install location.
>>
>>
>> If you have a "clean" prefix and relative install path for all binaries then you can safely use $ORIGIN 
>> see: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling
>>
>>  
>>
>>      - I prefer file(COPY) over install(FILES) because the former can set
>>        permissions with complex patterns. I appreciate that file(COPY) allows
>>        me to set executable permissions on *.so and binaries with a single
>>        invocation (in a loop over many directories).
>>
>>
>> if you install(TARGET ..) any binaries or .so would have the appropriate permissions precisely because cmake
>> knows what they are and does not consider them as "file" which is the case for install(FILES).
>>  
>>
>>     > one more question, could you tell us which version of CPack/CMake you are using?
>>
>>     I'm on the latest cmake 3.13 as of now, but I tested 3.12.4 as well.
>>
>>
>> Then you have all bleeding edge feature with you.
>>
>> I'm not trying to tell you what to do with your install, I'm just trying what CPack expects.
>>
>> install(DIRECTORY ...) is a kind of trap-them-all for things that are not installed otherwise, this is usually used for things like
>> generated documentation and not for "normally built artefact" like executable, libraries etc...
>>
>>
>> -- 
>> Eric
>



Viele Gruesse,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CPack RPM: file XXX conflicts with file from package filesystem-yyy...

Eric Noulard


Le mar. 27 nov. 2018 à 14:56, Mario Emmenlauer <[hidden email]> a écrit :

Dear Eric,

just to let you know, your suggestion of using a post-install-script
for all system-wide links and files was indeed the solution to a working
RPM package. Now my files are completely encapsulated in /opt/PKGNAME/
and install works fine.

Thank you very much for the *positive* feedback, we don't always get those :-)

This is nice to me and probably useful to others knowing it finally works.
 
Cheers,
Eric

Cheers and Thanks,

   Mario



On 23.11.18 15:37, Mario Emmenlauer wrote:
>
> Dear Eric,
>
> thanks a lot for this help! I think I have the pointers to move forward!
> One more detail below:
>
> On 23.11.18 11:36, Eric Noulard wrote:
>> Le ven. 23 nov. 2018 à 11:10, Mario Emmenlauer <[hidden email] <mailto:[hidden email]>> a écrit :
>>     Dear Eric, thanks for the help! Below more:
>>
>>     On 22.11.18 18:20, Eric Noulard wrote:
>>     > Le jeu. 22 nov. 2018 à 16:16, Mario Emmenlauer <[hidden email] <mailto:[hidden email]> <mailto:[hidden email]
>>     <mailto:[hidden email]>>> a écri
>>     >     I'm trying to build an RPM with CPack, and everything seems to work,
>>     >     but the resulting package can not be installed. I get Transaction check
>>     >     error:
>>     >       file / from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>>     >       file /opt from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>>     >       file /usr/bin from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>>     >       file /usr/share from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>>     >       file /usr from install of <mypackage> conflicts with file from package filesystem-3.2-25.el7.x86_64
>>     >
>>     >     I've read in the CPackRPM source code about how to add excludes and
>>     >     CPackRPM says that my "Final list of path to OMIT in RPM" would be
>>     >     /etc;/etc/init.d;/usr;/usr/bin;/usr/include;/usr/lib;/usr/libx32;/usr/lib64;/usr/share;/usr/share/aclocal;/usr/share/doc;/opt;/usr/share/applications
>>     >
>>     >
>>     > You can read the doc too:
>>     > https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST
>>
>>     Haha, done that! I've read everything I could find, including the
>>     docs and the excellent but hard-to-find community wiki at
>>     https://gitlab.kitware.com/cmake/community/wikis/home
>>
>>
>> OK then you are up-to-doc then.
>>
>>     >     Could someone shed some light? I believe that the problem may be
>>     >     my install command: I call install only once for the full tree
>>     >     of files that I'd like to package:
>>     >       install(DIRECTORY "${INSTALL_TMP_ROOT}/" DESTINATION "/" USE_SOURCE_PERMISSIONS)
>>     >
>>     > Yep this is looking for trouble.
>>     > How did you build the "${INSTALL_TMP_ROOT}" in the first place?
>>     >
>>     > Can't you use relative path install DESTINATION ? For all files/target you build?
>>
>>     I'm not sure if I can use a relative path. I want to build a system package
>>     that installs to /opt/<package>/ with symlinks in /usr/bin/ and desktop
>>     files in /usr/share/applications/. Since files go into different paths below
>>     system root (/opt, /usr, maybe /var) I assume I need to install into root?
>>     Maybe I misunderstand?
>>
>>
>> Not really. Usually you install in relative bin/ share/ man/ whatever other subdir you need.
>> Then you define CPACK_PACKAGING_INSTALL_PREFIX (see https://cmake.org/cmake/help/v3.13/variable/CPACK_PACKAGING_INSTALL_PREFIX.html)
>> to set up your "main" install prefix for your package. Every CPack generator has a default **packaging install prefix** (not to be confused with
>> CMAKE_INSTALL_PREFIX).
>> In your case: 
>> set(CPACK_PACKAGING_INSTALL_PREFIX "/opt") 
>> which should even be (AFAIR) the default value for RPM and DEB.
>>
>> Concerning the symlink in /usr/bin (or other places /usr/share etc...) this usually done using post-install script
>> https://cmake.org/cmake/help/v3.13/cpack_gen/rpm.html#variable:CPACK_RPM_SPEC_MORE_DEFINE
>>
>> the script itself may call standard symlink creation like https://linux.die.net/man/8/update-alternatives
>
> Aha, now I see the recommended approach! Makes perfect sense! So I will
> continue to bundle up everything, but try to avoid files outside my
> man package directory (for me /opt/${PROJECT_NAME}). Then I will make
> the system integration (to /usr/bin, /usr/share, etc) via symlinks
> and update-alternatives in post-install scripts. This makes perfect
> sense, I'm sorry I did not think of it myself!
>
> All the best,
>
>     Mario
>
>
>
>> Sometimes you *really* need absolute prefix like when you install in /etc/init...
>> then for those (generally system) specific file you install them with absolute destination.
>> CPackRPM is able to handle those as "config" file automatically.
>>
>>     >     I have a wild guess that this install somehow includes the
>>     >     directories, and probably it would be better to just call install
>>     >     on the individual files?
>>     >
>>     > CPack RPM tries its best to avoid shipping directories he does not need to ship, but
>>     > RPM requires that any new (non shared) directory should be specified in the spec file,
>>     > so CPackRPM tries to "discover that" automatically and make the package relocatable.
>>     >
>>     > Installing a whole directory to an absolute DESTINATION (even "/" in you case) is probably 
>>     > giving tough time to CPackRPM.
>>
>>     There is something I don't understand: I can see that CPackRPM removes
>>     several things from CPACK_RPM_INSTALL_FILES, but later rpm complains
>>     about several of the removed items nonetheless. For example /usr/bin.
>>     Does that mean the filtering failed, or does the filter work but (somehow)
>>     the directory still ends up being packaged?
>>
>>
>> Evil usually hides in details.
>>
>> Difficult to say without having the actual code and package to look into it.
>> Is your project public? If so could you provide us with the source?
>>
>> If not tries to setup a stripped down public project that exhibit the same issue.
>>  
>>
>>     >     I would prefer not to call install on the
>>     >     individual files because that overrides file permissions for every
>>     >     file, and I carefully prepared my package upfront to have the
>>     >     exact permissions for installation.
>>     >
>>     >
>>     > How did you "carefully prepared my package upfront" ?
>>     > And what do you mean by
>>     > "because that overrides file permissions for every file"
>>
>>     Currently I bundle my package in a temporary directory for three reasons:
>>      - Its easier for me to grasp. I.e. I can nicely inspect the package and
>>        see what will be bundled before the fact.
>>
>>
>> make/ninja DESTDIR=/tmp/testinstall all
>>
>> may be used equally for that.
>>  
>>
>>      - In the temporary copy, I can override RPATH on binaries and libraries
>>        without changing them in their actual install location.
>>
>>
>> If you have a "clean" prefix and relative install path for all binaries then you can safely use $ORIGIN 
>> see: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling
>>
>>  
>>
>>      - I prefer file(COPY) over install(FILES) because the former can set
>>        permissions with complex patterns. I appreciate that file(COPY) allows
>>        me to set executable permissions on *.so and binaries with a single
>>        invocation (in a loop over many directories).
>>
>>
>> if you install(TARGET ..) any binaries or .so would have the appropriate permissions precisely because cmake
>> knows what they are and does not consider them as "file" which is the case for install(FILES).
>>  
>>
>>     > one more question, could you tell us which version of CPack/CMake you are using?
>>
>>     I'm on the latest cmake 3.13 as of now, but I tested 3.12.4 as well.
>>
>>
>> Then you have all bleeding edge feature with you.
>>
>> I'm not trying to tell you what to do with your install, I'm just trying what CPack expects.
>>
>> install(DIRECTORY ...) is a kind of trap-them-all for things that are not installed otherwise, this is usually used for things like
>> generated documentation and not for "normally built artefact" like executable, libraries etc...
>>
>>
>> -- 
>> Eric
>



Viele Gruesse,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/


--
Eric

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake