Gratuitous change from init_samba_module to samba_init_module in master considered bad ...

[Richard Sharpe]

On Sat, Dec 31, 2011 at 1:36 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> On Fri, 2011-12-30 at 21:14 -0800, Jeremy Allison wrote:
>> On Fri, Dec 30, 2011 at 07:23:58PM -0800, Richard Sharpe wrote:
>> > Hi,
>> >
>> > It seems that in this commit, or there abouts:
>> > http://gitweb.samba.org/?p=samba.git;a=commit;h=7d33ec3dfe78723d62f4941684060baeb9c4bda6
>> >
>> > changed the name of the module init function from init_samba_module
>> > (which it was in Samba 3.5.x and 3.6.x) to samba_init_module. (I think
>> > I have that correct.)
>> >
>> > While all Samba VFS modules that are shared objects will be shielded
>> > from this change, all static modules will be forced to make changes
>> > that should not be needed.
>> >
>> > Did we really need to make that gratuitous change?
>>
>> And if not, shall we put it back the way it was ? :-)
>
> The original change was discussed on the list, as part of a package of
> changes to put all our module related functions in one namespace.  The
> change of the #define SAMBA_INIT_MODULE and it's value
> "samba_init_module" were discussed at the time.
>
> https://lists.samba.org/archive/samba-technical/2011-October/080070.html
>
> Now, part of that change has since been reverted - samba_modules.h is no
> longer a public header, and OpenChange simply implements it's own
> modules loading.
>
> https://lists.samba.org/archive/samba-technical/2011-December/080737.html
>
> I have no particular attachment to samba_init_module or
> init_samba_module, the change was simply to have a single consistent
> namespace.
>
> As a background, with all the other changes, particularly those required
> for the waf build (no undefined symbols are permitted, must link against
> the Samba libraries, VFS/auth/passdb interface changes), it seemed the
> init function name would not be a particularly difficult burden.

This will affect two groups of people when Samba 3.7 or whatever is
cut from master:

1. Those who build their VFS modules outside the Samba tree. There
would seem to be plenty of those, because many seem to now be basing
their product on RPMs and use, say, the SerNet RPMs.

2. Those who build on platforms that do not have shared libraries and
have their own VFS modules.

We can solve this by documentation (in the release notes, in my guide
to VFS Modules, where the issue first arose because I documented the
behavior in Master and then a reader wrote to inform me that I was
wrong :-)

-- 
Regards,
Richard Sharpe