On Mon, Jan 19, 2026 at 2:51 AM Rafael Sadowski <[email protected]> wrote: > > On Sun Jan 18, 2026 at 01:15:33PM -0500, Neal Gompa wrote: > > On Sun, Jan 18, 2026 at 11:30 AM Rafael Sadowski <[email protected]> > > wrote: > > > > > > On Mon Jan 19, 2026 at 01:18:59AM +0900, [email protected] wrote: > > > > OpenBSD has precompiled binary packages and > > > > > The ports tree is meant for advanced users. Everyone is encouraged > > > > to > > > > use the pre-compiled binary packages. > > > > > https://www.openbsd.org/faq/ports/ports.html > > > > So there is still a distinction between build-time and runtime. > > > > > > > > 2026/01/18 23:57 Neal Gompa <[email protected]>: > > > > > > > > On Sun, Jan 18, 2026 at 9:45 AM Rafael Sadowski > > > > <[email protected]> wrote: > > > > > > > > > > Hi KDE Community, > > > > > > > > > > I'm currently working on mapping the dependencies for the OpenBSD > > > > > packages properly. I've started analysing the .kde-ci.yml. > > > > > > > > > > In OpenBSD, we have RUN_-, BUILD_- and LIB_DEPENDS. RUN_DEPENDS > > > > must > > > > > be installed alongside the package. BUILD_DEPENDS must be present > > > > > at build time but not linked against lib/bin and finally > > > > LIB_DEPENDS > > > > > which link against bin/lib. > > > > > > > > > > Let's take a look at frameworkintegration-6.22.0 for example: > > > > > > > > > > We have the following LIB_DEPENDS: > > > > > > > > > > LIB_DEPENDS = devel/kf6/attica>=${MODKF6_VERSION} \ > > > > > devel/kf6/kcolorscheme>=${MODKF6_VERSION} \ > > > > > devel/kf6/kconfig>=${MODKF6_VERSION} \ > > > > > devel/kf6/kcoreaddons>=${MODKF6_VERSION} \ > > > > > devel/kf6/ki18n>=${MODKF6_VERSION} \ > > > > > devel/kf6/kiconthemes>=${MODKF6_VERSION} \ > > > > > devel/kf6/knewstuff>=${MODKF6_VERSION} \ > > > > > devel/kf6/knotifications>=${MODKF6_VERSION} \ > > > > > devel/kf6/kwidgetsaddons>=${MODKF6_VERSION} > > > > > > > > > > That's easy, because we scan all bin/libs to determined all used > > > > > libs correctly. This This is recorded in WANTLIB. This means that > > > > > it is immediately apparent if something is missing: > > > > > > > > > > WANTLIB += ${COMPILER_LIBCXX} GL KF6Attica KF6ColorScheme > > > > KF6ConfigCore > > > > > WANTLIB += KF6CoreAddons KF6I18n KF6IconThemes KF6NewStuffCore > > > > > WANTLIB += KF6Notifications KF6WidgetsAddons Qt6Core Qt6DBus > > > > Qt6Gui > > > > > WANTLIB += Qt6Network Qt6Widgets c m > > > > > > > > > > In other words, we can correctly determine shared library > > > > dependencies, but > > > > > now it gets exciting, but .kde-ci.yml says even more > > > > dependencies, > > > > namely: > > > > > > > > > > KDE_DEPENDS = devel/kf6/kconfigwidgets \ > > > > > devel/kf6/kguiaddons \ > > > > > devel/kf6/kio \ > > > > > devel/kf6/kitemviews \ > > > > > devel/kf6/oxygen-icons \ > > > > > devel/kf6/kpackage > > > > > > > > > > I determined KDE_DEPENDS based on kde-ci.yml. Now I'm wondering > > > > > how to deal with it. Are these just build dependencies, or also > > > > > runtime dependencies, or both? What's the best way to determine > > > > > this? Can I even do that? What would be the best strategy for > > > > > distributions? > > > > > > > > > Correct me if I'm wrong, but don't ports imply that these things > > > > are > > > > compiled on the user's computer? Doesn't that mean the distinction > > > > of > > > > build-time and run-time is not particularly strong? > > > > -- > > > > > > We build the official packages from the ports. I take care of the KDE/Qt > > > ports > > > so that we can distribute the packages cleanly with all dependencies. > > > > > > The build time is particularly very strong because our distributed ports > > > builder depends on all dependencies being present in order to compile > > > the port into a package (for the official packages). > > > > > > RUN_DEPENDS is important because when the user installs the package, it > > > ensures that all RUN_DEPENDS and LIB_DEPENDS are installed. > > > > > > > So at least with RPM distributions (and to a lesser extent Debian as > > well), most runtime dependencies are automatically populated by > > reading the binaries and identifying the packages that include the > > libraries. That leaves largely the QML stuff and executables to be > > added as dependencies manually. > > > > Do you have a mechanism to do something similar with your ports? > > > > As already described, yes we have the binary/libraries analysis. > Referring to the example above for frameworkintegration: kpackage is NOT > a dependency of libraries/binaries but appears in .kde-ci.yml. How to > deal with this: is it ONLY a build dependency OR ONLY a run dependency > OR both? > > The AND or OR or BOTH is my challenge. >
That is typically a build-only dependency. If something *only* appears in KDE CI, it's either a build-time only dependency or something that exists for the benefit of KDE CI. I would omit it unless the build fails, then add it as a build-time dependency. -- 真実はいつも一つ！/ Always, there's only one truth!
