[DTrace-devel] [PATCH] Bump up the version to 2.0.4

[Kris Van Hees]

On Sat, Oct 25, 2025 at 03:02:34PM -0400, Eugene Loh wrote:
> On 10/25/25 02:05, Kris Van Hees wrote:
> 
> > On Fri, Oct 24, 2025 at 11:44:46PM -0400, eugene.loh at oracle.com wrote:
> > > From: Eugene Loh <eugene.loh at oracle.com>
> > > 
> > > Note that test/unittest/preprocessor/tst.predefined.sh checks that the
> > > __SUNW_D_VERSION preprocessor symbol is consistent with the "dtrace -vV"
> > > message, and both of them simply use the last entry of versions.list and
> > > therefore will be consistent for in-tree builds.
> > > 
> > > When RPM packages are built from the .spec file, however, _DT_VERSION,
> > > used for the "dtrace -vV" "This is" message, comes from the .spec file.
> > This is actually not correct.  THe value of _DT_VERSION is always provided
> > by the GNUmakefile, which takes it from its own VERSION macro, which in fact
> > is set to the highest (most current) version of DTrace based on versions.list.
> > 
> > So, the version that DTrace reports is always provided by the highest version
> > listed in versions.list.
> > 
> > The version that is specified in the spec file is only used as version of the
> > RPMs that are built from it.
> 
> I'm confused.  E.g., with the 2.0.4 RPMs we're testing:
> 
> $ sudo /usr/sbin/dtrace -vV
> dtrace: D 2.0.3
> This is DTrace 2.0.4
> dtrace(1) version-control ID: 1ac1d4aaf8fb2ffa21187eb9e5227a487f7fcd40
> libdtrace version-control ID: 1ac1d4aaf8fb2ffa21187eb9e5227a487f7fcd40
> 
> The "2.0.3" is _dtrace_version, which is DT_VERS_STRING, which is the
> highest version mkvers finds in versions.list.
> 
> The "2.0.4" is _DT_VERSION, which, um, okay, yeah, is set by GNUmakefile,
> which I guess gets it from "mkvers -vcurrent=t versions.list".
> 
> So if versions.list was missing 2.0.4, then how in the world could the RPM
> build report 2.0.4?  Where does that value come from?

I think that the issue is found in the following line in GNUmakefile:

INVARIANT_CFLAGS := -std=gnu99 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 $(if $(NATIVE_BITNESS_ONLY),-DNATIVE_BITNESS_ONLY) -D_DT_VERSION=\"$(VERSION)\"

For regular builds, that seems to be taking its value from

VERSION := $(shell ./libdtrace/mkvers -vcurrent=t libdtrace/versions.list)

whereas for rpm builds, it seems to take its value from

make -j $(getconf _NPROCESSORS_ONLN) VERSION=%{version} \
        %{bpfc} %{maybe_use_fuse2}

That is the only explanation I can come up with.

This seems (to me) another case where versioning cleanup is needed.  I think
that the version string should be defined by the build rather than the
spec file.  The version in the spec file should not be anything but the
version of the packaging.  The version of the implementation really ought to
be handled by the source code tree itself.