On 2026/09/17 12:35, Stuart Lamble wrote: > Thanks. I've decided to try to compile it through the ports packaging system, > which turned out to be a rabbit hole: 3.2 uses meson as the build system, and > it's been quite the learning curve to sort out the dependencies and get it to > build cleanly. It's almost there, for some undefinable value of "almost" and > "there". > > The main query I have at the moment is that it looks for krb5-gssapi as part > of the build process. I can get that easily enough with heimdal, but the > question is whether it would be desirable to build it without that library or > not. (It's used for GSS-TSIG on dynamic DNS updates). For testing purposes it > doesn't matter, but it could be important for some use cases.
I would disable it for now. That is something we'd normally do by adding a gssapi flavour if needed rather than compiling unconditionally, e.g. as in openldap, dovecot, cyrus-sasl2. Emphasis on "if needed" - I think I'd prefer if someone had an actual need for it before adding, rather than doing it preemptively (reducing the number of combinations to check for updates is helpful; having somebody who actually uses the functionality who can shout if it gets broken is also helpful). > Leaning towards having separate flavours: one bare bones; one each for > PostgreSQL and MySQL; and two variants of all three - with and without > GSS-TSIG. (acknowledging that there have been issues with the PostgreSQL > support in the past and that it was turned off once boost 1.87+ was packaged, > so that might end up being another rabbit hole.) Just unflavoured and mysql as per the current port would be fine, if postgresql builds without hassle then might as well include it, but not having that certainly isn't a blocker to updating. > General comments and advice on this would be welcome. (If you're going to do > something, do it properly...) > > As a side note, I have the updated port for log4cplus working; in light of > Stuart H's comment about it being held back because of Kea, I'm not going to > submit the diff to this channel until I have an updated Kea operational as > well. (Feel free to ask me for that diff if you want it. I just don't want > confusion about whether it should be updated or not until the blocker has > been properly resolved.) Thanks :)
