mini-snmpd package 1.6 (current) actually ships mini_snmpd 1.4rc1 (3-4 year old version)

[arigit]

@marcin1j

In package: mini_snmpd - 1.6-1
The actual binary that's shipped is actually version 1.4-rc1, not 1.6

mini_snmpd -h
Mini snmpd v1.4-rc1 -- Minimal SNMP daemon for embedded UNIX systems

Usage: mini_snmpd [options]

  -4, --use-ipv4         Use IPv4, default
  -6, --use-ipv6         Use IPv6
...

I could see there was a version bump, here: #13409
However it seems the version bump was just the package name, not the actual version of upstream shipped, is this possible?

mini_snmpd version 1.6 includes support of ifXtable / 64 bit counters for interfaces, specifically OID 1.3.6.1.2.1.31.1.1.1, this is embedded in the source code, it was introduced in version 1.5 (I can see it in the source), however the shipped package binary does not know about this OID. and also it shows as version 1.4rc1

[neheb]

Yeah. This package was never updated. Amazing.

[marcin1j]

Bummer.

I'll switch package source to codeload to avoid such mishap in the future. There's no longer need to reference untagged git commits.

[marcin1j]

@neheb

It looks like upstream has changed binary name to mini-snmpd (troglobit/mini-snmpd@a905e33) . Should we keep an old mini_snmpd package name or adapt it to match source repository?

[neheb]

I don't have a strong opinion. mini_snmpd can be kept as a package name, PKG_NAME is only really used for downloading the file.

[marcin1j]

If source code is retrieved from codeload, PKG_BUILD_DIR has to be overridden to match archive structure, otherwise build fails.
We would need to override PKG_SOURCE too if we wanted to keep tarball name in download directory consistent with upstream (mini-snmpd-1.6.tar.gz vs mini_snmpd-1.6.tar.gz). This also introduces disparity between binary name (mini-snmpd) and uci config/init.d name (mini_snmpd).

On the other hand changing package name breaks both devices' installed package list and /etc/config entry. I'd consider fixing this spurious version bump a hotfix (keeping old package name) but in the long run we should somehow adapt upstream package name.
Is there any established migration path or best pratice in such cases?

[arigit]

@marcin1j related to the name change (underscore for score), I am not sure if this issue belongs here or belongs to downstream / entware, however there is a problem in the initd file for this service,

cd /opt/etc/init.d

# cat S50mini_snmpd 
#!/bin/sh

ENABLED=yes
PROCS=mini-snmpd
ARGS="-i br0,eth0 -D super_router -L xyz -c zyx -C my@mail.com"
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/opt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func

however the binary name uses the underscore

# which mini_snmpd
/opt/bin/mini_snmpd

So to get the service to work normally, one has to manually edit S50mini_snmpd
and change the score with an underscore

[marcin1j]

@arigit What init script you are referring to? This is neither upstream Debian nor OpenWRT.

Speaking of OpenWRT, the daemon and init script is going to work correctly regardless of package name.

[arigit]

@arigit What init script you are referring to? This is neither upstream Debian nor OpenWRT.

Understood! must be and entware thing. I will report this downstream, together with the ask to re-sync once the new release of this package (1.6-2?) is out

Thanks a lot for the fast response on this one

[marcin1j]

You have to wait for revision 3 to become available your repository. Note that daemon binary path has changed from /usr/bin/mini_snmpd to /usr/sbin/mini-snmpd.