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? -- 真実はいつも一つ！/ Always, there's only one truth!
