I'd like to add a special construct to dependencies, "=" to mean the exact version of the package we're depending on.
The patch is trivial: Index: OpenBSD/PackingElement.pm =================================================================== RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackingElement.pm,v retrieving revision 1.283 diff -u -p -r1.283 PackingElement.pm --- OpenBSD/PackingElement.pm 28 Jun 2022 08:15:43 -0000 1.283 +++ OpenBSD/PackingElement.pm 1 Nov 2022 18:20:37 -0000 @@ -1079,7 +1079,13 @@ OpenBSD::Auto::cache(spec, require OpenBSD::Search; my $self = shift; - return OpenBSD::Search::PkgSpec->new($self->{pattern}) + my $src; + if ($self->{pattern} eq '=') { + $src = $self->{def}; + } else { + $src = $self->{pattern}; + } + return OpenBSD::Search::PkgSpec->new($src) ->add_pkgpath_hint($self->{pkgpath}); }); (This takes advantage of the fact that PkgSpec comparisons have an implicit = if no operator has been mentionned) This would result in lines like @depend archivers/libarchive:=:libarchive-3.6.1p0 meaning "hey I want to depend on the exact version of libarchive we have". There are several reasons behind this patch. - most of the stuff that wants exact version comparison has to go through hoops to get it. - register-plist can't flag changes in PKGSPEC as relevant, because... with exact version comparisons, those change ALL THE TIME. I would be able to say "hey, you changed PKGSPEC, you want to bump the dependant port". Because, in the way we do things, PKGSPEC changes are almost invariably to restrict/move the dependency along so that we don't end up with broken dependency tree (case in point: the introduction of gimp-3.x which broke all dependency chains for gimp-2.x) The only downside I see to this is that this will be the exact version, including REVISION, whereas a few ports shun the REVISION part while making the comparison. Testing this patch on debug packages is trivial: Index: bsd.port.mk =================================================================== RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v retrieving revision 1.1580 diff -u -p -r1.1580 bsd.port.mk --- bsd.port.mk 1 Nov 2022 10:55:54 -0000 1.1580 +++ bsd.port.mk 3 Nov 2022 07:05:12 -0000 @@ -1203,7 +1203,7 @@ _pkg_cookie${_S} = ${_PACKAGE_COOKIE${_S . if ${DEBUG_PACKAGES:M${_S}} _DBG_PKG_ARGS${_S} := ${PKG_ARGS${_S}} -_DBG_PKG_ARGS${_S} += -P${FULLPKGPATH${_S}}:${FULLPKGNAME${_S}}:${FULLPKGNAME${_S}} +_DBG_PKG_ARGS${_S} += -P${FULLPKGPATH${_S}}:=:${FULLPKGNAME${_S}} _DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${PKGSTEM${_S}}" _DBG_PKG_ARGS${_S} += -d"-debug info for ${FULLPKGNAME${_S}}" # XXX revisit that fullpkgpath later ? There is also a slightly more involved patch to extend the *_DEPENDS = some/path>=2.1 glue so that *_DEPENDS = some/path= works Index: bsd.port.mk =================================================================== RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v retrieving revision 1.1580 diff -u -p -r1.1580 bsd.port.mk --- bsd.port.mk 1 Nov 2022 10:55:54 -0000 1.1580 +++ bsd.port.mk 1 Nov 2022 18:20:54 -0000 @@ -1602,16 +1602,20 @@ ERRORS += "Fatal: old style depends ${_C # the C,...., part basically does this: # if the depends contains only pkgpath>=something # then we rebuild it as STEM->=something:pkgpath +# also, pkgpath= becomes =:pkgpath .for _v in BUILD LIB RUN TEST ${_v}_DEPENDS := ${${_v}_DEPENDS:C,^([^:]+/[^:<=>]+)([<=>][^:]+)$,STEM-\2:\1,} +${_v}_DEPENDS := ${${_v}_DEPENDS:C,^([^:]+/[^:=]+)=[^:]*$,=:\1,} .endfor .for _v in BUILD TEST ${_v}_DEPENDS := ${${_v}_DEPENDS:C,^([^:]+/[^:<=>]+)([<=>][^:]+)(:patch|:configure|:build)$,STEM-\2:\1\3,} +${_v}_DEPENDS := ${${_v}_DEPENDS:C,^([^:]+/[^:=]+)=[^:]*)(:patch|:configure|:build)$,=:\1\2,} .endfor .for _s in ${MULTI_PACKAGES} . for _v in RUN LIB ${_v}_DEPENDS${_s} := ${${_v}_DEPENDS${_s}:C,^([^:]+/[^:<=>]+)([<=>][^:]+)$,STEM-\2:\1,} +${_v}_DEPENDS${_s} := ${${_v}_DEPENDS${_s}:C,^([^:]+/[^:=]+)=[^:]*$,=:\1,} . endfor .endfor Obviously, this involves a bit of patience, because the pkg_add change needs to trickle down to snapshots before the other parts can go in. Any objection to moving forward with this ?