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 ?
