new port: kf6archive

[jwrober]

See #44808

• Changes comply with the maintainer guide.
• The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
• Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx.
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is accurate. See adding-usage for context.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is in the new port's versions file.
• Only one version is added to each modified port's versions file.

This is my first vcpkg port, setting to draft initially.

[jwrober]

@microsoft-github-policy-service agree

[jwrober]

All the failures look like this. Why is ninja failing on some platforms, but not others?

CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:127 (message):
    Command failed: "C:/Program Files/Microsoft Visual Studio/2022/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe" -v
    Working Directory: D:/b/kf6archive/x86-windows-rel/vcpkg-parallel-configure
    Error code: 1

[Osyotr]

You have to look at the configure log.

CMake Error: Could not open file for write in copy operation D:/b/kf6archive/src/v6.7.0-619a9ab2f9.clean/.clang-format.tmp
CMake Error: : System Error: Permission denied
CMake Error at D:/installed/x64-windows/share/ECM/kde-modules/KDEClangFormat.cmake:67 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  D:/installed/x64-windows/share/ECM/kde-modules/KDEFrameworkCompilerSettings.cmake:64 (include)
  CMakeLists.txt:39 (include)

[dg0yt]

Why is ninja failing on some platforms, but not others?

CMake Error: Could not open file for write in copy operation D:/b/kf6archive/src/v6.7.0-619a9ab2f9.clean/.clang-format.tmp
CMake Error: : System Error: Permission denied
CMake Error at D:/installed/x64-windows/share/ECM/kde-modules/KDEClangFormat.cmake:67 (configure_file):
  configure_file Problem configuring file

So it is not a platform thing. The configuration step writes to the source directory. This is a a race when vcpkg configures release and debug binary directories at the same time. If you cannot turn off the step which writes to the source dir, you can add DISABLE_PARALLEL_CONFIGURE to the vcpkg_cmake_configure arguments.

[jwrober]

Well bummer that didn't seem to do the trick.

[Osyotr]

This is new:

Installing in D:/p/kf6archive_x86-windows/debug. Run D:/b/kf6archive/x86-windows-dbg/prefix.sh to set the environment for KArchive.
CMake Error at D:/downloads/tools/cmake-3.30.1-windows/cmake-3.30.1-windows-i386/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
  Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Call Stack (most recent call first):
  D:/downloads/tools/cmake-3.30.1-windows/cmake-3.30.1-windows-i386/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
  D:/downloads/tools/cmake-3.30.1-windows/cmake-3.30.1-windows-i386/share/cmake-3.30/Modules/FindPkgConfig.cmake:114 (find_package_handle_standard_args)
  D:/a/_work/1/s/scripts/buildsystems/vcpkg.cmake:896 (_find_package)
  CMakeLists.txt:73 (find_package)

Hint: #31357

[jwrober]

Thanks for the hint. I'll have a look at PkgConfig too.

[jwrober]

I'm not sure of the error for the x86_windows CI run that passed everywhere else. I "think" I setup to have the CI skip the Android platforms. I think a newer version of ECM will fix the issue, so its kind of a chicken-egg situation there. All the other platforms look looks and match what our project needs (windows and osx)

[vicroms]

I have a couple of questions regarding the KDE Framework libraries.

Is version 5 still being maintained? Does it offer a LTS version?

This seems to be in a similar situation to Qt, but do we really need to keep both versions around? If the answer to any of the previous questions is "no", then we should update the existing port and maybe rename it.

[jwrober]

For transparency, I am not a Qt nor a KDE Frameworks developer. I support an open source game that leverages Qt and the KfArchive library. Hence the port here for the Qt6 one. As I understand it based on a read here the Qt5 frameworks are in maintenance mode. I believe that is the same with Qt 5.15, which is the last of the Qt v5 LTS series. Frameworks don't do LTS, only Qt does. While Qt6 has been out now for awhile and has an LTS in v6.8, the development libraries are kind of new in the Linux world, especially Frameworks libraries.

My suggestion is to keep both v5 and v6 for both Qt and the KDE Frameworks. It's going to take some time for everyone using Qt5 to get over to Qt6 I'll wager. KDE Frameworks v6 library packages aren't even in Ubuntu LTS yet. That won't happen until 26.04 I think. They were not included in 24.04. Also, I think this port of kf6archive is the only KDE Frameworks port on any library on Qt6. There is an open issue for the rest of them, but I only need the one so took it under myself to add it here.

Hope this helps.

[lmoureaux]

Hi! The situation is indeed a bit complicated.

Qt 5 is officially end-of-life, but still gets (commercial) extended support by the Qt Company. (Some of?) the changes are committed to the repos on GitHub. Kde maintains an unversioned fork based on this + other fixes they backport from Qt 6. This is used by Linux distributions that ship Qt 5 (e.g. Arch). Vcpkg uses the last release by the Qt Company (link).

The latest Kde Frameworks 5 release was 5.116.0 on Sat May 19, 2024. This is used in Kde Plasma 5.27 LTS, which is still supported and had a release in January. Given the ties between Frameworks and Plasma, The Kde Qt fork and Kde Frameworks will be supported at least as long as Plasma is. There has been no end-of-life announcement so far.

[BillyONeal]

Qt 5 is officially end-of-life, but still gets (commercial) extended support by the Qt Company.

According to https://endoflife.date/qt , OSS support for qt5 ended 4 years, 7 months ago, and commercial support ended 2 months ago.

I think that supports flipping vcpkg's canonical version of qt to qt6 for all downstream ports that must pick one. We already did this in e.g. qtapplicationmanager.

[BillyONeal]

My suggestion is to keep both v5 and v6 for both Qt and the KDE Frameworks.

Do the KDE frameworks take steps to not step on each others' symbols for different versions such that they can be simultaneously installed? Most libraries do not do that, qt is special for doing so. Most of the time we can usually only pick one.

[lmoureaux]

Frameworks 5 and 6 can be installed next to each other but not linked together in the same executable. For instance, Arch Linux has both karchive and karchive-qt5. On my Ubuntu-based distro, I have:

/usr/lib/x86_64-linux-gnu/libKF5Archive.so.5.116.0
/usr/lib/x86_64-linux-gnu/libKF6Archive.so.6.15.0

[BillyONeal]

Unfortunately vcpkg's registry models a single link domain so if they can't be linked together I think we have to pick one to be the canonical one for the curated registry.

[jwrober]

@BillyONeal Are you suggesting we name this port kfarchive? This would follow how Qt6 is ported e.g. qt-base is Qt6 and qt5-base is Qt5

[lmoureaux]

(the framework name is karchive so it should be something like kf-karchive or just karchive, but it's customary to prefix kf with the version, as in kf6)

[BillyONeal]

No, I wasn't suggesting a name change, I was trying to say "can we take this at all while kf5archive exists". My understanding was that qt provided the link domain separation thing making it OK but after doing some digging with @vicroms and @ras0219-msft today it appears qt might not actually provide that unless you go out of your way to set the "namespace" for it to be in, and it doesn't appear we do that.

Which means this seems to be providing the same guarantees that our qt ports are already providing, which seems like it has to be OK then even if it breaks msbuild customers that try to install both.

Digging on repology looking for other kfXxx things e.g. https://repology.org/project/kio/versions our existing kf5Xxx are getting marked as part of that "project". The most common naming pattern is either no numbering at all, or kfX-name . Unfortunately that makes us a 'special snowflake' with kf5Xxx because we have no dash, but that's unfortunately too late to be worth changing now. Given that we're considering having both, I think the name already proposed here, kf6archive, is correct.

[jwrober]

Anything else for this PR to be approved and merged?

[BillyONeal]

Thanks for the new port!