Package: dpkg-dev
Version: 1.22.11
Severity: wishlist
Trying to figure out what exactly the various variables from pkg-info.mk return, I added a number of 'debug' statements to my (modified) clone of ffmpeg package repo's debian/rules file and got the following results:
```
$DEB_VERSION = 7:7.1-9.1
$DEB_VERSION_EPOCH_UPSTREAM = 7:7.1
$DEB_VERSION_UPSTREAM_REVISION = 7.1-9.1
$DEB_VERSION_UPSTREAM = 7.1
```
ffmpeg's debian/rules file also had this statement:
```
# Get the Debian version revision:
DEB_REVISION := $(word 2, $(subst -, ,$(DEB_VERSION)))
```
which returns "9.1".
It seems useful if pkg-info.mk could return that value too?
On Tue Dec 17, 2024 at 4:32 AM CET, Guillem Jover wrote:
On Mon, 2024-11-25 at 18:40:09 +0100, Diederik de Haas wrote:
Trying to figure out what exactly the various variables from pkg-info.mk return, I added a number of 'debug' statements to my (modified) clone of ffmpeg package repo's debian/rules file and got the following results:
Hmm, wasn't the comment header at the top of the file not clear
enough? If so I think that deserves to be improved, which I've tried
with the attached patch.
The main problem I had is that based on the description I could make a (somewhat educated) guess as to what a variable would return, while I
needed to know exactly what I would be getting back.
As usual, once you *know* you can then see/follow the logic that was
used, but (in my case) I needed debug statements to *know*.
The attached patch is an improvement :-)
But do (also) consider adding a practical (fictitious) example like I
did with the ffmpeg version.
I'm not sure these are something common enough to want to extract
though, and my codesearch.debian.net search imagination is failing me
(or giving me too many false positives for SOURCE_DATE_EPOCH).
That is (ofc) a maintainers call, but my thought was: if you already
provide most version parts in variables, why not all? The cost seems negligible to *me* as you already have done 90% of the work needed?
You're obviously much more fluent in Makefile syntax/parsing then I am,
so it would be great if someone like you could provide it then me trying
to come up with something ... which (in my case) usually means searching
on codesearch and hoping/assuming that that other person did it correctly.
I looked into this due to the debian-rules-parses-dpkg-parsechangelog
lintian message. Not providing all the parts *could* mean people would
still need to do that ... for that tiny bit that is NOT provided in pkg-info.mk.
On Mon, 2024-11-25 at 18:40:09 +0100, Diederik de Haas wrote:
Package: dpkg-dev
Version: 1.22.11
Severity: wishlist
Trying to figure out what exactly the various variables from pkg-info.mk return, I added a number of 'debug' statements to my (modified) clone of ffmpeg package repo's debian/rules file and got the following results:
Hmm, wasn't the comment header at the top of the file not clear
enough? If so I think that deserves to be improved, which I've tried
with the attached patch.
```
$DEB_VERSION = 7:7.1-9.1
$DEB_VERSION_EPOCH_UPSTREAM = 7:7.1
$DEB_VERSION_UPSTREAM_REVISION = 7.1-9.1
$DEB_VERSION_UPSTREAM = 7.1
```
ffmpeg's debian/rules file also had this statement:
```
# Get the Debian version revision:
DEB_REVISION := $(word 2, $(subst -, ,$(DEB_VERSION)))
```
which returns "9.1".
It seems useful if pkg-info.mk could return that value too?
A problem I guess is that in contrast to all the existing version
variable, this one can be empty for native packages. Which could be documented, and if added I guess we might need to add also a variable
to extract the epoch for symmetry.
I'm not sure these are something common enough to want to extract
though, and my codesearch.debian.net search imagination is failing me
(or giving me too many false positives for SOURCE_DATE_EPOCH).
On Tue, 2024-12-17 at 11:24:30 +0100, Diederik de Haas wrote:
On Tue Dec 17, 2024 at 4:32 AM CET, Guillem Jover wrote:
On Mon, 2024-11-25 at 18:40:09 +0100, Diederik de Haas wrote:
Trying to figure out what exactly the various variables from pkg-info.mk
return, I added a number of 'debug' statements to my (modified) clone of
ffmpeg package repo's debian/rules file and got the following results:
The main problem I had is that based on the description I could make a (somewhat educated) guess as to what a variable would return, while I needed to know exactly what I would be getting back.
But do (also) consider adding a practical (fictitious) example like I
did with the ffmpeg version.
I guess given the optional nature of the epoch and revision, I'd need
to add at least three versions and their values for each variable.
Hmm. :) Will see whether that does not end up very cluttered.
That is (ofc) a maintainers call, but my thought was: if you already provide most version parts in variables, why not all? The cost seems negligible to *me* as you already have done 90% of the work needed?
I looked into this due to the debian-rules-parses-dpkg-parsechangelog lintian message. Not providing all the parts *could* mean people would still need to do that ... for that tiny bit that is NOT provided in pkg-info.mk.
Ah, the debian-rules-parses-dpkg-parsechangelog lintian tag! Ok, then
I see where you are coming from, and why just for this alone that would
make sense. I think there's indeed also a point of being complete about
what gets exposed.
My initial apparent reluctance was coming from thinking about a potential future where dpkg-buildpackage can obsolete all these make fragment files, and provide the information itself, and how that could end up polluting
the environment for all children processes, for example.
In any case, I'll try to get something going.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 151:08:47 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,797 |