Bug 6444 - *.dat files end up in "wrong" directory
*.dat files end up in "wrong" directory
Status: RESOLVED FIXED
Product: Samba 3.5
Classification: Unclassified
Component: Build environment
unspecified
Other Linux
: P3 enhancement
: ---
Assigned To: Michael Adam
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-06 07:53 UTC by Debian samba package maintainers (PUBLIC MAILING LIST)
Modified: 2010-01-20 06:14 UTC (History)
1 user (show)

See Also:


Attachments
patch: make codepagedir configurable (1.07 KB, patch)
2009-09-26 17:07 UTC, Michael Adam
bjacke: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Debian samba package maintainers (PUBLIC MAILING LIST) 2009-06-06 07:53:33 UTC
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...
Comment 1 Michael Adam 2009-09-22 17:57:03 UTC
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
Comment 2 Michael Adam 2009-09-26 16:58:36 UTC
Is the bug assigned for 3.5 by error?
It seems that 3.4 is meant...
Comment 3 Michael Adam 2009-09-26 17:07:32 UTC
Created attachment 4754 [details]
patch: make codepagedir configurable
Comment 4 Michael Adam 2009-11-20 18:44:25 UTC
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.
Comment 5 Debian samba package maintainers (PUBLIC MAILING LIST) 2009-11-26 15:45:56 UTC
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
Comment 6 Karolin Seeger 2010-01-20 06:14:21 UTC
(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!