Closed Raffaello closed 7 months ago
i guess is something auto-geneerated with CPack default parameters
You are correct. The RPM package is set up at line 1246 in the root CMakeLists.txt
. What parameter(s) should we add to indicate these are shared system directories? I would welcome a PR to fix this as I have no experience with RPM and do not have Fedora available.
@MarkCallow I'll have a look. but it might not be so simple reaching the bottom of it as there is no specfile. on the other hand it could be simple as a CMake/CPack bug fixed in a newer version...
@MarkCallow I have done a preliminary check with the latest code on main
branch.
I have done a first basic buld as a per BUILDING.md
doc and then executed a CPack
for rpm
.
tried installing the package and no conflicts where reported.
CMake version: 3.27.7 gcc: gcc (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6) ninja: 1.11.1
here the RPM Spec file generated by CMake:
# Restore old style debuginfo creation for rpm >= 4.14.
%undefine _debugsource_packages
%undefine _debuginfo_subpackages
# -*- rpm-spec -*-
BuildRoot: %_topdir/KTX-Software-4.3.0-beta1-Linux-x86_64
Summary: Libraries and tools to create and read KTX image texture files.
Name: ktx-software
Version: 4.3.0
Release: 1
License: unknown
Group: unknown
Vendor: Khronos Group
Url: https://github.khronos.org/KTX-Software
Prefix: /usr
%define _rpmdir %_topdir/RPMS
%define _srcrpmdir %_topdir/SRPMS
%define _rpmfilename KTX-Software-4.3.0-beta1-Linux-x86_64.rpm
%define _unpackaged_files_terminate_build 0
%description
Copyright 2015-2020 The Khronos Group Inc.
SPDX-License-Identifier: Apache-2.0
This will install the following KTX tools along with libktx:
- ktx2check - Check KTX v2 files for validity.
- ktxinfo - Print info about a KTX file in human-readable form.
- ktx2ktx2 - Convert a KTX v1 file to a KTX v2 file.
- ktxsc - Supercompress a KTX v2 file.
- toktx - Create a KTX v1 or v2 file from .jpg, .png or Netpbm images.
It also installs the header files for development.
# This is a shortcutted spec file generated by CMake RPM generator
# we skip _install step because CPack does that for us.
# We do only save CPack installed tree in _prepr
# and then restore it in build.
%prep
mv $RPM_BUILD_ROOT %_topdir/tmpBBroot
%install
if [ -e $RPM_BUILD_ROOT ];
then
rm -rf $RPM_BUILD_ROOT
fi
mv %_topdir/tmpBBroot $RPM_BUILD_ROOT
%clean
%files
%defattr(-,root,root,-)
"/usr/bin/ktx"
"/usr/bin/ktx2check"
"/usr/bin/ktx2ktx2"
"/usr/bin/ktxinfo"
"/usr/bin/ktxsc"
"/usr/bin/toktx"
%dir "/usr/include/KHR"
"/usr/include/KHR/khr_df.h"
%dir "/usr/include/fmt"
"/usr/include/fmt/args.h"
"/usr/include/fmt/chrono.h"
"/usr/include/fmt/color.h"
"/usr/include/fmt/compile.h"
"/usr/include/fmt/core.h"
"/usr/include/fmt/format-inl.h"
"/usr/include/fmt/format.h"
"/usr/include/fmt/os.h"
"/usr/include/fmt/ostream.h"
"/usr/include/fmt/printf.h"
"/usr/include/fmt/ranges.h"
"/usr/include/fmt/std.h"
"/usr/include/fmt/xchar.h"
"/usr/include/ktx.h"
"/usr/include/ktxvulkan.h"
%dir "/usr/lib/cmake"
%dir "/usr/lib/cmake/ktx"
"/usr/lib/cmake/ktx/KtxConfig.cmake"
"/usr/lib/cmake/ktx/KtxConfigVersion.cmake"
"/usr/lib/cmake/ktx/KtxTargets-noconfig.cmake"
"/usr/lib/cmake/ktx/KtxTargets.cmake"
%dir "/usr/lib64/cmake"
%dir "/usr/lib64/cmake/fmt"
"/usr/lib64/cmake/fmt/fmt-config-version.cmake"
"/usr/lib64/cmake/fmt/fmt-config.cmake"
"/usr/lib64/cmake/fmt/fmt-targets-noconfig.cmake"
"/usr/lib64/cmake/fmt/fmt-targets.cmake"
"/usr/lib64/libfmt.a"
"/usr/lib64/libktx.so"
"/usr/lib64/libktx.so.4"
"/usr/lib64/libktx.so.4.3.0"
%dir "/usr/lib64/pkgconfig"
"/usr/lib64/pkgconfig/fmt.pc"
%changelog
* Sun Jul 4 2010 Eric Noulard <eric.noulard@gmail.com> - 4.3.0-1
Generated by CPack RPM (no Changelog file were provided)
At the moment i am thinking is the way to generate the RPM in the CI that might not be ok:
It looks like the RPM is built in Travis CI using Ubuntu. If it is true, might be this scenario to create a small issue? I can't test it, but just speculating that the CMake/Cpack deriving some information through the OS Environment might misinterpret something and generating something not ok, or even the build of the pacakge might be different of USER/GROUP ID or some subtle difference.
Querying the RPM packages files and permissions there is a subtle difference on the directory KHR
:
this is the one generated within Ubuntu, downloaded with github:
drwxrwxr-x root:root /usr/include/KHR
-rw-r--r-- root:root /usr/include/KHR/khr_df.h
This one is the one i have generated natively on Fedora:
drwxr-xr-x root:root /usr/include/KHR
-rw-r--r-- root:root /usr/include/KHR/khr_df.h
basically the /usr/include/KHR
has 0755
permissions as "correct", instead the one generated in Travis CI has 0775
permissions.
So this is a reason for the conflict already.
I am going to try to figure it out here in this repo how can be "corrected", maybe there is some CPACK_RPM_*
to set to define some specific attributes and might fixes without changing to much, but i think a better solution would be to build RPM on a RedHat OS, this maybe might be done through Docker like emscriptten, or must create a specific CI job using a RedHat OS if any is available for free...
@MarkCallow i created this PR #830 , i can't guarantee 100% it will fix it, but it looks promising.
Querying the RPM packages files and permissions there is a subtle difference on the directory KHR:
this is the one generated within Ubuntu, downloaded with github:
drwxrwxr-x root:root /usr/include/KHR -rw-r--r-- root:root /usr/include/KHR/khr_df.h
This is indeed an Ubuntu OS thing. I've reproduced it on my local Ubuntu set up. Here is the relevant section of /etc/login.defs
# If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value
# for private user groups, i. e. the uid is the same as gid, and username is
# the same as the primary group name: for these, the user permissions will be
# used as group permissions, e. g. 022 will become 002.
My user and the build user on Travis CI both have private user groups hence the umask is 002
so directories are created with mode 775
and copied by RPM. Your PR is the correct way to fix this. I will test it locally.
On Fedora 39, installing 4.2.1 reports this error:
It looks like the conflicts is due by a previous install of
SDL2
that depends onlibglvnd-devel
there is a file located there:
The point is it is conflicting with the
/usr/include/KHR/
directory, not with the file itself.The same issue is for the
/usr/share/man
directory: It already exists and it report as a conflict.I didn't find any
CPACK_RPM_USER_BINARY_SPECFILE
to point to a rpm.spec
file to look into it and find the possible error, so i guess is something auto-geneerated with CPack default parameters that makes the install target directory mandatory to be not present, like if it is not a system directory to be shared among other packages.