search

KhronosGroup / KTX-Software

KTX (Khronos Texture) Library and Tools
Other
854 stars 226 forks source link

libglvnd-devel conflict when installing KTX-Software-4.2.1 x86_64 RPM on Fedora with a pre-installed SDL2 #827

Closed Raffaello closed 7 months ago

Raffaello commented 7 months ago

On Fedora 39, installing 4.2.1 reports this error:

rpm -ivh  KTX-Software-4.2.1-Linux-x86_64.rpm 
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
    file /usr/share/man from install of ktx-software-4.2.1-1.x86_64 conflicts with file from package filesystem-3.18-6.fc39.x86_64
    file /usr/include/KHR from install of ktx-software-4.2.1-1.x86_64 conflicts with file from package libglvnd-devel-1:1.7.0-1.fc39.x86_64

It looks like the conflicts is due by a previous install of SDL2 that depends on libglvnd-devel

there is a file located there:

ll /usr/include/KHR/
total 12
-rw-r--r--. 1 root root 11131 Sep 12 15:02 khrplatform.h

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.

MarkCallow commented 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.

Raffaello commented 7 months ago

@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...

Raffaello commented 7 months ago

@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...

Raffaello commented 7 months ago

@MarkCallow i created this PR #830 , i can't guarantee 100% it will fix it, but it looks promising.

MarkCallow commented 7 months ago

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.