Re: How to determine runtime-/build-only dependencies
[email protected] Mon, 19 Jan 2026 20:03:27 +0900
| Newsgroups | gmane.comp.kde.devel.general |
|---|---|
| Message-ID | <[email protected]> |
It includes Both runtime and build time dependencies. There is a RuntimeDependencies field for deps that are Only runtime dependencies but that is inconsistently applied. 2026/01/19 16:51 Rafael Sadowski <[email protected]>: 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. Rafael