Re: [PATCH] Bump up the version to 2.0.4

On 10/25/25 22:42, Kris Van Hees wrote:

> 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, [email protected] wrote:
>>>> From: Eugene Loh <[email protected]>
>>>>
>>>> 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.

Right.  So that version number *IS* coming from the .spec file.

> 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.

Okay.  So, the .spec file *shouldn't* be specifying VERSION in that make 
line.  I'll go with that understanding and post a v2.