<div dir='auto'>It includes Both runtime and build time dependencies.<div dir="auto">There is a RuntimeDependencies field for deps that are Only runtime dependencies but that is inconsistently applied.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2026/01/19 16:51 Rafael Sadowski <rafael@sizeofvoid.org>:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">On Sun Jan 18, 2026 at 01:15:33PM -0500, Neal Gompa wrote:
<br>
> On Sun, Jan 18, 2026 at 11:30 AM Rafael Sadowski <rafael@sizeofvoid.org> wrote:
<br>
> >
<br>
> > On Mon Jan 19, 2026 at 01:18:59AM +0900, mail@kisaragi-hiu.com wrote:
<br>
> > > OpenBSD has precompiled binary packages and
<br>
> > > > The ports tree is meant for advanced users. Everyone is encouraged to
<br>
> > > use the pre-compiled binary packages.
<br>
> > > > https://www.openbsd.org/faq/ports/ports.html
<br>
> > > So there is still a distinction between build-time and runtime.
<br>
> > >
<br>
> > > 2026/01/18 23:57 Neal Gompa <ngompa13@gmail.com>:
<br>
> > >
<br>
> > > On Sun, Jan 18, 2026 at 9:45 AM Rafael Sadowski
<br>
> > > <rafael@sizeofvoid.org> wrote:
<br>
> > > >
<br>
> > > > Hi KDE Community,
<br>
> > > >
<br>
> > > > I'm currently working on mapping the dependencies for the OpenBSD
<br>
> > > > packages properly. I've started analysing the .kde-ci.yml.
<br>
> > > >
<br>
> > > > In OpenBSD, we have RUN_-, BUILD_- and LIB_DEPENDS. RUN_DEPENDS
<br>
> > > must
<br>
> > > > be installed alongside the package. BUILD_DEPENDS must be present
<br>
> > > > at build time but not linked against lib/bin and finally
<br>
> > > LIB_DEPENDS
<br>
> > > > which link against bin/lib.
<br>
> > > >
<br>
> > > > Let's take a look at frameworkintegration-6.22.0 for example:
<br>
> > > >
<br>
> > > > We have the following LIB_DEPENDS:
<br>
> > > >
<br>
> > > > LIB_DEPENDS = devel/kf6/attica>=${MODKF6_VERSION} \
<br>
> > > > devel/kf6/kcolorscheme>=${MODKF6_VERSION} \
<br>
> > > > devel/kf6/kconfig>=${MODKF6_VERSION} \
<br>
> > > > devel/kf6/kcoreaddons>=${MODKF6_VERSION} \
<br>
> > > > devel/kf6/ki18n>=${MODKF6_VERSION} \
<br>
> > > > devel/kf6/kiconthemes>=${MODKF6_VERSION} \
<br>
> > > > devel/kf6/knewstuff>=${MODKF6_VERSION} \
<br>
> > > > devel/kf6/knotifications>=${MODKF6_VERSION} \
<br>
> > > > devel/kf6/kwidgetsaddons>=${MODKF6_VERSION}
<br>
> > > >
<br>
> > > > That's easy, because we scan all bin/libs to determined all used
<br>
> > > > libs correctly. This This is recorded in WANTLIB. This means that
<br>
> > > > it is immediately apparent if something is missing:
<br>
> > > >
<br>
> > > > WANTLIB += ${COMPILER_LIBCXX} GL KF6Attica KF6ColorScheme
<br>
> > > KF6ConfigCore
<br>
> > > > WANTLIB += KF6CoreAddons KF6I18n KF6IconThemes KF6NewStuffCore
<br>
> > > > WANTLIB += KF6Notifications KF6WidgetsAddons Qt6Core Qt6DBus
<br>
> > > Qt6Gui
<br>
> > > > WANTLIB += Qt6Network Qt6Widgets c m
<br>
> > > >
<br>
> > > > In other words, we can correctly determine shared library
<br>
> > > dependencies, but
<br>
> > > > now it gets exciting, but .kde-ci.yml says even more dependencies,
<br>
> > > namely:
<br>
> > > >
<br>
> > > > KDE_DEPENDS = devel/kf6/kconfigwidgets \
<br>
> > > > devel/kf6/kguiaddons \
<br>
> > > > devel/kf6/kio \
<br>
> > > > devel/kf6/kitemviews \
<br>
> > > > devel/kf6/oxygen-icons \
<br>
> > > > devel/kf6/kpackage
<br>
> > > >
<br>
> > > > I determined KDE_DEPENDS based on kde-ci.yml. Now I'm wondering
<br>
> > > > how to deal with it. Are these just build dependencies, or also
<br>
> > > > runtime dependencies, or both? What's the best way to determine
<br>
> > > > this? Can I even do that? What would be the best strategy for
<br>
> > > > distributions?
<br>
> > > >
<br>
> > > Correct me if I'm wrong, but don't ports imply that these things are
<br>
> > > compiled on the user's computer? Doesn't that mean the distinction
<br>
> > > of
<br>
> > > build-time and run-time is not particularly strong?
<br>
> > > --
<br>
> >
<br>
> > We build the official packages from the ports. I take care of the KDE/Qt ports
<br>
> > so that we can distribute the packages cleanly with all dependencies.
<br>
> >
<br>
> > The build time is particularly very strong because our distributed ports
<br>
> > builder depends on all dependencies being present in order to compile
<br>
> > the port into a package (for the official packages).
<br>
> >
<br>
> > RUN_DEPENDS is important because when the user installs the package, it
<br>
> > ensures that all RUN_DEPENDS and LIB_DEPENDS are installed.
<br>
> >
<br>
>
<br>
> So at least with RPM distributions (and to a lesser extent Debian as
<br>
> well), most runtime dependencies are automatically populated by
<br>
> reading the binaries and identifying the packages that include the
<br>
> libraries. That leaves largely the QML stuff and executables to be
<br>
> added as dependencies manually.
<br>
>
<br>
> Do you have a mechanism to do something similar with your ports?
<br>
>
<br>
<br>
As already described, yes we have the binary/libraries analysis.
<br>
Referring to the example above for frameworkintegration: kpackage is NOT
<br>
a dependency of libraries/binaries but appears in .kde-ci.yml. How to
<br>
deal with this: is it ONLY a build dependency OR ONLY a run dependency
<br>
OR both?
<br>
<br>
The AND or OR or BOTH is my challenge.
<br>
<br>
Rafael
<br>
</p>
</blockquote></div><br></div>