herb at sgi.com
Mon Nov 12 08:19:08 GMT 2001
David Brodbeck wrote:
> What would be really great (though is seldom done in most software, in my
> experience) would be if, instead of just spitting the old parameters back as
> syntax errors, the error log would give some clue as to where to look for
> the new ones. (e.g., "Parameter 'security' is no longer supported, see
> 'server role'.)
As the person that has to maintain the supported version of Samba for
this has a direct impact on me.
I tend to agree with Andrew that new major releases are the only chance
we have to really clean things up on an interface level. We do have
a precedent for removing parameters even in minor releases (share
While it does present problems when options disappear and people do not
read the release notes (you will always get those type of people) this
can be handled by fixing testparm. We could add a new flag that only
spits out unknown parameters with the above type of message telling the
person where to look for the replacement functionality. This could be
run as part of the install process if there is an existing smb.conf
file. The output from the existing testparm is just too verbose for
this kind of check and important things might get missed.
Every time I teach a course on Samba I try to get people used to the
"real" parameter name and not use aliases. If you allow SWAT to rewrite
your smb.conf it will automatically change any alias to the "real"
name. If people are not aware of the aliases they may get confused
when they see their smb.conf changed and their favorite parameter
just disappeared. I think a new major release may be a good chance
to reduce the number of confusing aliaes as well.
So the bottom line for me is that it is OK to change the interface
for a major release as long as it is well documentated what has
changed and what you need to do to maintain the same functionality
when you upgrade.
my 2 cents
More information about the samba-technical