[kea-dev] OpenBSD: Kea 1.2.0

[Patrik Lundin]

On Mon, Jul 24, 2017 at 12:52:01PM +0200, Marcin Siodelski wrote:
> > 
> > As mentioned in
> > https://lists.isc.org/pipermail/kea-users/2017-July/001050.html I am
> > currently updating the Kea port in OpenBSD to 1.2.0.
> > 
> > First of all I notice that while the majority of the shared libraries
> > have an explicit version configured using the "-version-info" flag in
> > the Makefiles, there are a few that do not:
> > ===
> > kea-asiodns (src/lib/asiodns/Makefile.am)
> > kea-exceptions (src/lib/exceptions/Makefile.am)
> > kea-util-io (src/lib/util/io/Makefile.am)
> > ===
> > 
> 
> We leave them in their defaults which is 0:0:0 and that's what we
> consider is their current version. None of these libraries have been
> recently updated and they will rarely be.
> 
> > Is there a reason for this or is it just an oversight? In general it
> > seems the other ones have settings along these lines:
> > ===
> > libkea_cfgclient_la_LDFLAGS = -no-undefined -version-info 3:0:0
> > ===
> > 
> 
> The other libraries have explicit versions added because they are
> updated from the release to release and for each library which code have
> been updated we bump up version numbers prior to a Kea release. If a
> library is at version 0:0:0 and its code haven't been updated we just
> leave the implicit version. If we happen to update the code in any of
> those libs in the future it will be followed by a version bump, so it
> will be given an explicit version-info, e.g. 1:0:0.
> 

The main thing that makes this a bit confusing is that there are
currently two libraries that are explicitly configured to 0:0:0:
===
src/lib/http/Makefile.am:libkea_http_la_LDFLAGS += -no-undefined -version-info 0:0:0
src/lib/process/Makefile.am:libkea_process_la_LDFLAGS += -no-undefined -version-info 0:0:0
===

This makes it difficult to understand if a library that is missing a
explicit version string is doing so because it is "supposed to
default to 0:0:0" or if it has been forgotten.

Would it hurt to always be explicit? If nothing else it makes it easy to
update once it is suppused to be incremented in the future.

> > The reason I ask about this is that port Makefiles in OpenBSD keep track
> > of SHARED_LIBS version numbers. It helps me out a lot when there is clear
> > indication that a library version needs to be bumped because of changes by
> > upstream.
> > 
> 
> Is it possible for the port Makefiles to simply assume that no
> version-info means version 0?
> 

The reported result currently lists the unconfigured libraries as
version "unknown". This will be treated as 0:0:0.

> > I also noticed one of the version numbers went backwards in 1.2.0 in
> > comparision to 1.1.0. kea-dns++ went from 2.0 to 1.1. It can be seen in
> > src/lib/dns/Makefile.am, git commit 88d32454640a1f5f80fc4cd75339647be0210426.
> > Was this a mistake or am I missing something?
> > 
> 
> Yes, we had made some mistakes in the versioning of this library in the
> past, i.e. the version number had been bumped too high. In one of the
> recent releases we amended this version number to what it should be. I
> realize it is strange to go backwards but the current version is what it
> should be.
> 

Thanks for the info. I guess this is the reason the Makefile keeps it's
own versioning scheme since I can then increment it to reflect a later
version even if upstream jumps back and forth :).

> > As Mike noted in the above mentioned thread Kea 1.2.0 requires a more
> > modern compiler and because of that I am using clang. The build fails in
> > the following way without patches:
[...]
> > 
> > This was fixed by Marc Espie (espie@) prior to me starting to look at
> > 1.2.0 here:
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/net/kea/patches/patch-src_lib_util_watch_socket_cc
> > 
> > I'm thinking it is a good candidate for being merged upstream.
> > 
> 
> I agree. I don't see any problem with porting this fix into Kea. In fact
> I have just done it.
> 

Great, then I can drop the patch in a later version.

> > I also noticed that while a ticket i previously filed
> > (https://kea.isc.org/ticket/5072) has been solved, and the lfc-interval
> > has been added to a bunch of places in the repo, it has not been added
> > to the src/bin/keactrl/kea.conf.pre file which ends up as the default
> > kea.conf. Is this intentional? I also notice "persist" is not configured
> > by default, even if this seems to be strongly encouraged in the
> > documentation.
> > 
> 
> Kea configuration allows for omission of some of the configuration
> parameters causing the servers to fallback to the defaults. For the sake
> of config readability we purposely omit some of the parameters in the
> default configuration file.
> 
> As for "persist", we don't specify it explicitly in the default config
> file and let be the default true (enabled). Note that if we put the
> "persist": true into the default config we'd give an impression that
> this is a parameter that can be controlled just like other parameters,
> while we rather want people to not disable it.
> 

That makes sense for the persist keyword, thanks. I still wonder about
lfc-interval though. It appears to default to 0, and has been explicitly
set to 3600 in example configs (though not in src/bin/keactrl/kea.conf.pre).

This makes me wonder if either "kea.conf.pre" should be updated with an
explicit lfc-interval of 3600, or if the default should be changed from
0 to 3600 and the lines removed from all example configurations again.

-- 
Patrik Lundin