On Wed, Jan 7, 2026 at 05:58 Stuart Henderson <[email protected]> wrote:
> On 2026/01/06 17:44, Morgan Aldridge wrote:
> > Updated to latest version 4.0.0. Tested with Gandi protocol.
> >
> > I've attached to prevent my MUA breaking the diff.
> >
> > It looks like Pascal's 3.11.2 patch[0] from 2024-03-01 (attached for
> > reference; see questions below) never got any feedback and the 3.10.0
> > patch[1] (not attached) was never committed (only one OK from sdk@?)
> >
> > The 3.11.2 patch still applies and builds for me, but I didn't run-test
> > it as I need 4.0.0 for some auth changes in the Gandi protocol. I did
> > notice that it restores the use of daemon class in PLIST's @newuser,
> > which ajacoutot@'s commit in r1.29 explicitly removed.
> >
> > The daemon class was also restored in the PLIST in my 4.0.0 patch
> > when I ran `make plist`. The order of some of the samples also
> > differs from Pascal's 3.11.2 patch, which looks to result in slightly
> > different file permissions for installed examples.
> >
> > Should I manually re-order the PLIST and remove the daemon class?
>
> update-plist shouldn't touch the class, so not sure what happened there.
> it should be removed.
I think I didn't fully reset PLIST between Pascal's 3.11.2 patch and
development of my 4.0.0 patch. Oops!
> +CONFIGURE_STYLE=gnu autoreconf
>
> just autoreconf is enough
Perfect, thanks!
> +AUTOMAKE_VERSION= 1.12
> > +AUTOCONF_VERSION= 2.63
>
> hardly any ports use those old versions - probably only when upstream
> already provided configure scripts and we're patching the input files,
> so we want the same version for comparison. that doesn't apply here so
> use versions which are more likely to be installed already (easier for
> manual builds, less churn in bulks).
Very good to know. I was going by the autoconf version in configure.ac and
_clearly_ being far too conservative with the automake version (just
bumping it to the minimum required version.)
Even better, using these versions also negates the need for my patch
removing the extraneous semicolon in configure.ac.
> +SYSCONFDIR= ${BASESYSCONFDIR}/ddclient
>
> upstream changed things in 4.0 so that doesn't work properly (looks in
> /etc/ddclient/ddclient), just drop it
Also nice.
> +MAKE_ENV= runstatedir=/var/run/ddclient
>
> doesn't seem to do anything. set it via CONFIGURE_ARGS instead.
Thanks, I missed that!
> +FAKE_FLAGS= sysconfdir=${PREFIX}/share/examples
> > +
> > +BUILD_DEPENDS= net/curl
>
> no need for the BDEP, just pass in the path via CONFIGURE_ARGS
Oh, nice.
> +RUN_DEPENDS= net/curl \
> > net/p5-IO-Socket-INET6 \
> > security/p5-IO-Socket-SSL
>
> it uses curl instead of the other deps (see changelog), so drop them
I also missed this. Doh!
> -NO_BUILD= Yes
> > -NO_TEST= Yes
>
> missing some test deps (there's one that we don't have in ports,
> HTTP::Daemon::SSL, but most tests don't need it)
I did notice that there were a couple failing tests, but most were passing
and my run-testing was successful. I should have been more diligent here,
but was clearly a little too rushed trying to get something working for
production.
> post-extract:
> > - @sed -i -e "s,/var/cache/ddclient/,/var/db/ddclient/,g;" \
> > - -e "s,/etc/ddclient/,${SYSCONFDIR}/ddclient/,g" \
> > - ${WRKSRC}/ddclient
> ..
> > + @sed -i -e "s,/cache/ddclient,/db/ddclient,g" \
> > + ${WRKSRC}/{ddclient.in,Makefile.am}
>
> better use a standard patch rather than sed here.
>
> how's this diff instead? I don't have any ddns stuff for runtime tests
> but 'make test' looks promising.
This looks _much_ better, applies cleanly, builds and installs without
issue, and my run-testing has been successful. Currently running it in
production, so I'll report back if I experience any issues over time. I
suspect anything that comes up would probably be best addressed upstream
and/or in-tree anyway.
Of course, I'm only currently using the Gandi protocol. Pascal had been
using different providers with the 3.11.2 patch, but I'm not sure if is
still using ddclient. As you and Pascal have both pointed out, 4.0.0 is a
_huge_ update over the 3.9.1 that we currently package, so this could use
more run-testing.
Again, huge thanks for the detailed review and updated patch! I can't OK,
but two thumbs-up from me.
Morgan
