2

I've just completed a simple source code modification & rebuild on a Raspberry Pi OS - bullseye machine. Because this is new to me, I'll list the steps I followed in an effort to avoid ambiguity:

$ dhcpcd --version
dhcpcd 8.1.2                            # "before" version
$ sudo apt install devscripts           # build tools for using `debuild`
$ apt-get source dhcpcd5                # creates source tree ~/dhcpcd5-8.1.2; Debian git repo is far off!
$ cd dhcpcd5-8.1.2                      # cd to source dir
$ nano src/dhcp.c                       # make required changes to the source (one line)
~/dhcpcd5-8.1.2 $ debuild -b -uc -us    # successful build
$ cd ..
$ sudo dpkg -i dhcpcd5_8.1.2-1+rpt5_armhf.deb # install .deb file created by debuild
$ dhcpcd --version
dhcpcd 8.1.2                            # "after" version
$

All well & good, but the "before" & "after" version numbers are exactly the same, which leaves me without a simple way to know whether I have my corrected code running, or the un-corrected code. I'll install the corrected .deb file to several hosts, I may get requests from others, etc, so I'd like some way to easily distinguish corrected from un-corrected code.

Using dhcpcd --version seems an easy way to do this. I've read that Debian has rules re version numbers, but as I'm not releasing this to "the world" I see no need for formality. Also - I've submitted a pull request/merge request to the Debian repo, and I've advised the RPi organization on the issue. I've gotten no feedback from either party, but this bug is a huge annoyance for me. I don't wish to wait for a new release of dhcpcd with a "proper" version number.

What must I do to cause the corrected version of dhcpcd to report dhcpcd 8.1.2.1 - or something similar?

EDIT for Clarification:

Based on this answer, I edited dhcpcd5-8.1.2/debian/changelog. Following this change, the apt utilities consistently report the version of dhcpcd as 8.1.3:

$ apt-cache policy dhcpcd5
dhcpcd5:
  Installed: 1:8.1.3-1+rpt1
  Candidate: 1:8.1.3-1+rpt1
  Version table:
 *** 1:8.1.3-1+rpt1 100
        100 /var/lib/dpkg/status
     1:8.1.2-1+rpt1 500
        500 http://archive.raspberrypi.org/debian buster/main armhf Packages
     7.1.0-2 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
$ #
$ dpkg -s dhcpcd5 | grep Version
Version: 1:8.1.3-1+rpt1 
$

However: dhcpcd --version still reports 8.1.2. dhcpcd is aliased to dhcpcd5 in /etc/alternatives. Consequently, dhcpcd --version is actually dhcpcd5 --version. It appears that the executable dhcpcd5 is getting its --version from a different source than than apt utilities.?

EDIT 2:

Turns out the version # that gets reported by dhcpcd --version is defined in defs.h as follows:

#define PACKAGE                 "dhcpcd"
#define VERSION                 "8.1.2"

I think dhcpcd is a bit of an outlier. The RPi team apparently decided to forego the upstream version 9 when released (years ago), and have stuck to version 8.1.2 even though there were several upstream releases following ver 8.1.2. Still more confusing is the fact that the .dsc file lists Vcs-Browser: https://salsa.debian.org/smlx-guest/dhcpcd5 as the Git repo - but it's actually stuck at version 7. This doesn't make much sense to me - I guess that's one reason I'm not a package maintainer. :)

Seamus
  • 2,522
  • 1
  • 16
  • 31

1 Answers1

4

You can either add the relevant lines at the top of debian/changelog (find here details on the contents of that file).

You can duplicate the current top stanza and change the version number (making an useful log comment is a good idea).

Alternatively you can use the dch tool (from devtools):

dch --local your_package_name

Once installed, you can check the installed version of the package with something like this (there are alternatives)

dpkg -l dhcpcd5

Upstream version identifiers cannot be automatically imported because they don't always officially exist (say python3-lzss) and when they do, they might not be compatible with the restrictions and sorting of the package system versions. For example epoch is needed sometimes to migrate from upstream to Debian versions.

Eduardo Trápani
  • 12,032
  • 1
  • 18
  • 35
  • That does not seem to work. I edited `debian/changelog`. I copied the earlier entry, added it to the top of the file, then carefully edited it. The .deb file produced was `dhcpcd5_8.1.2.1-1+rpt1_armhf.deb`, but after `dpkg -i ...` `dhcpcd --version` still reports 8.1.2. Also tried changing to 8.1.3 => `dhcpcd5_8.1.3-1+rpt1_armhf.deb`, but `dhcpcd --version` still reports 8.1.2. – Seamus Apr 10 '22 at 06:08
  • Tried `dch --local dhcpcd` with the same result as direct editing `debian/changelog`. My manual edits were bumped down 1 place, I re-edited, but got the same result. `dhcpcd` still thinks it is 8.1.2 - but it's not. I can see the difference my patch made, and a patched version is running. – Seamus Apr 10 '22 at 06:29
  • 2
    @Seamus The package version and the tool-which-is-packaged-within version are two separate things. To change the tool's version you must edit its sources. For each tool that would be a different manner, each time requiring to read and understand its source. – A.B Apr 10 '22 at 08:51
  • @A.B: Yes - I have just figured that out :P And I suppose that makes this a 2-part answer. Eduardo's answer was for a question I didn't actually ask, but part of the solution nevertheless. Would you like to post your answer for an upvote? – Seamus Apr 10 '22 at 09:32
  • 1
    Short of finding out where the version number is set for the application (in some cases it might be on a library built from the same source), the way to have **some way to easily distinguish** (your question) is to do a `dpkg -l dhcpcd5`. Changing the version in the source *and* in the package can be time consuming and error prone if you just want to easily find out the binary you are running. – Eduardo Trápani Apr 10 '22 at 15:41
  • Thanks Eduardo - I guess I am the last person on the planet to learn that the process of building a `.deb` package doesn't automatically flow version info from the `debuild` process back into the source code. I'm not good w/ `C` - I assumed there was a macro or env var that took care of that. `dpkg -l` is also very useful. FWIW, I feel your answer would be improved & potentially more useful by adding some of the info here in the comments. – Seamus Apr 10 '22 at 22:02