On Tue, Jan 20, 2026 at 12:09 AM Neal Gompa <[email protected]> wrote:
> 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. > In some cases a dependency on CI can just be superfluous as the system doesn't punish or try to stop you from adding unnecessary dependencies, and it trusts that what has been filled in is required. It's easy enough to do if someone is copying around .kde-ci.yml files rather than starting from scratch. The only downside is the system having to pull more things in (however the build nodes locally cache dependencies even between runs, so even this is minimal) > > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > Thanks, Ben
