For Debian packages we build with the following: --with-modulesdir=/usr/lib/samba \ --datarootdir=/usr/share \ --datadir=/usr/share/samba \ --with-swatdir=/usr/share/samba/swat \ --with-lockdir=/var/run/samba \ --with-statedir=/var/lib/samba \ --with-cachedir=/var/cache/samba \ The point is having files landing in the "right" place wrt FHS. According to the FHS, *.dat files, that are architecture-independent should end up in /usr/share/samba...and indeed they always have in Debian packages, with the FHS patches we had...prior to 3.4 With our patches integrated to 3.4, everything is now fine...except the location for these *.dat files. Despite using "--datadir=/usr/share/samba" files end up in /usr/lib/samba. I guess this is because Makefile.in has this: CODEPAGEDIR = @codepagedir@ ...but I see no way to specify "codepagedir" through configure. The "fix" we used was this: Index: samba-3.4.0pre1/source3/Makefile.in =================================================================== --- samba-3.4.0pre1.orig/source3/Makefile.in +++ samba-3.4.0pre1/source3/Makefile.in @@ -156,7 +156,7 @@ STATEDIR = @statedir@ # Where to look for (and install) codepage databases. -CODEPAGEDIR = @codepagedir@ +CODEPAGEDIR = @datadir@ # the directory where pid files go PIDDIR = @piddir@ I see this as a "trick" and I'm unsure this is the "right" fix but, at least, that fixes our problem..:-) Could this, or any other similar fix that would really allow *.dat files location to be configurable be considered for 3.4? Many thanks in advance...
Hi, I just pushed a patch to master which makes the codepage dir configurable via a new "--with-codepagedir=DIR" parameter to configure. I am going to post a backported version for v3-4-test here, soon. We may think about changing the default, at least in FHS mode, too. Michael
Is the bug assigned for 3.5 by error? It seems that 3.4 is meant...
Created attachment 4754 [details] patch: make codepagedir configurable
With codepage being configurable at configure-time, does this solve the bug for you? This will be in 3.5. Debian folks: Did you mean 3.4? I don't think that it would be problematic to get it into 3.4.4. We already have positive review.
I don't see this as mandatory for 3.4. We have a Debian patch to do what we want, so including the fix in 3.5 is IMHO enough. Of course, if you still include the fix in 3.4, we won't cry..:-) Christian
(In reply to comment #5) > I don't see this as mandatory for 3.4. We have a Debian patch to do what we > want, so including the fix in 3.5 is IMHO enough. > > Of course, if you still include the fix in 3.4, we won't cry..:-) As the patch adds a new configure option, I would prefer not to add it to 3.4.x. Closing out bug report. Thanks!