moving libaddns top-level and "merging" libcli/dns

[Kai Blin]

On 2012-05-25 08:14, Alexander Bokovoy wrote:

> WAF build is strict on linking the same code twice in resulting
> binaries. DNS_HOSTS_FILE subsystem was independently linked in
> multiple places that, when their real dependencies were fixed, ended
> up linked into the same binaries.

That's not really a reason to merge a testing hack with an
in-development library aimed at production use.


>>
>> I also think that we really, really should try to get rid of libaddns,
>> and not mark it as "ok to be used project-wide" by moving it to the top
>> level.
> As you are doing a lot of DNS related activities, please look around
> into not only DNS updates or DNS server but also into resolver code.
> Up until recently there were four different resolver libraries across
> Samba code base, all replicating each other with minor or major
> differences in structures, parameters, and ways they call back into
> system-provided resolver API. Making things available at a central
> place (libaddns) was an attempt to get duplication down.

That I am well aware of, and that is exactly why I started a canonical
implementation based around an IDL-generated parser and an async client
library. However I'm not paid to work on Samba, and need to focus the
time I have on one feature at a time. But that doesn't meant I can't
have an opinion on how our DNS code should be developed. libaddns, as
far as I'm aware, is completely untested, blocking, and hand-marshalled.

> I'm not against doing IDL-based DNS code at all. What I'm contesting
> here is half-completeness, to the level that we even have some
> structures defined twice with the same name and different content,
> IDL-based and otherwise. Whether it comes from an old code or recent
> additions, duplicate symbols and structures are welcoming to
> confusion, both for developers and compilers/linkers.

libaddns was used in source3 only, and I didn't want to touch that until
the libcli/dns implementation was more advanced. Don't blame me for the
fact that source3 has some DNS code duplicated, part of that has been
around for longer than I have been a project member.

I'm saying that by putting a library in the top level, it's your job to
make sure it's clean and doesn't break other stuff that already is in
the top level.

> So instead of killing libaddns' "common use", please look into how to
> get unifying our disorganised resolvers. This does not mean it has to
> be public library in terms of us exporting its interfaces to 3rd
> parties, it only means that it should be used across Samba code,
> without duplicated pieces of it here and there.

Right, that's the plan for libcli/dns, and you're currently busy making
this harder than necessary. If you don't have time to fix dns client
side correctly, please don't make life harder for people who want to.
I'm unclear what a scenario where merging two unrelated subsystems into
one library is the right solution looks like, but the current one
clearly isn't one of them.

Cheers,
Kai

-- 
Kai Blin
Worldforge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/