samba-3.0.0beta1 codeset issue on non-Linux
rsharpe at richardsharpe.com
Mon Jun 16 16:58:16 GMT 2003
On Mon, 16 Jun 2003, David Lee wrote:
> On Sat, 14 Jun 2003, Andrew Bartlett wrote:
> > On Sat, 2003-06-14 at 13:13, TAKAHASHI Motonobu wrote:
> > > [David Lee had earlier written:]
> > >
> > > >> b) Bundle iconv (or part) with samba?
> > > >I'm not sure this would be a good solution.
> > >
> > > is the only reasonable solutions, I think.
> > No, I don't think that including iconv() in samba in reasonable. Why is
> > it better to have iconv inside samba than outside?
> Samba has always prided itself on its portablity to a wide range both of
> systems and of managerial environments. It has been careful to mimimise
> the chain-of-prerequisite syndrome that has afflicted some other software.
> Accordingly it seems we ought to try, so far as is reasonably practicable,
> to work with the OS-provided "iconv()". But _if_ we decide that Samba
> really has to use GNU-iconv, in whole or part, then that decision by the
> Samba Team (guided the participants in this thread) needs to be very well
> defended. And we then need to know how to handle the many sites which,
> though having OS-iconv don't have GNU-iconv.
> Technically, would "configure" screech to a halt, saying "You must first
> install GNU-iconv"?
> And what about those sites with a strict and cautious managerial/political
> policy, where the sysadmin has already had to fight hard locally to get
> Samba approved, only then to discover that s/he is back at square one and
> now has to re-fight the same battle w.r.t. GNU-iconv.
> Making GNU-iconv a pre-requisite might run the risk of losing many
> potential users.
I think it would be bad to require GNU libiconv. :-)
Other reasons include those NAS vendors that are using Samba and would
like to avoid dragging in yet another GPL'd package :-)
> But now let's step back from that brink.
> Is there not some way that we could let Samba choose and use a wide
> variety of "iconv"? And that we provide some "fall back" options (and a
> structure?) to handle as many of the common cases as often as possible.
> Such as a code page to handle CP850<->UTF8 and/or CP850<->UCS-2LE, and
> others that folk might contribute? (Would this be re-inventing a simpler,
> restricted GNU-iconv?)
> See also Richard Sharpe's parallel thread about BSD.
In fact, I believe that the native iconv on both Solaris and FreeBSD allow
for CP850<->UTF8 and CP850<->UCS-2LE, but neither seem to handle US-ASCII
(ASCII) to UCS-2LE, which is the test in Configire.
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org,
More information about the samba-technical