[Pkg-samba-maint] nearly built 3.2.0~pre2-1

Christian Perrier bubulle at debian.org
Fri Mar 28 06:45:37 UTC 2008


Quoting Christian Perrier (bubulle at debian.org):
> This morning, I attempted to build 3.2.0~pre2 after Steve's excellent
> work on merging trunk in our experimental branch.


I added libtalloc-dev and tdb-dev to Build-Depends but that's
apparently not enough.

Discussion happened between Michael Adam (obnox) and Steve Langasek
(vorlon) on IRC:

1:19 < obnox> bubulle, vorlon: it is libtalloc, libtdb, libnetapi, and libwbclient that must be found
21:20 < vorlon> the last two aren't packaged separately, we probably need to include them as part of the samba
                packaging
21:20 < obnox> yep
21:20 < obnox> they are internal to samba
21:20 < vorlon> well, unless one uses coffeedude's separate libwbclient, which we aren't yet :)
21:20 < obnox> :)
21:20 < id10ts> jelmer: do you recall why the provision code treats netbios names longer than 13 characters (as
                opposed to 15) as being invalid?  the check is in the validation code you added in Sep 2005
                (commit 87f25fe49caa78422582337c5208a331ef5b8c15)
21:22 < obnox> vorlon: are you putting the libs (libetapi at least) into /usr/lib/samba or /usr/lib or where?
21:23 < vorlon> obnox: either /usr/lib, or statically linked
21:24 < vorlon> I suppose /usr/lib is the better choice
21:25 < obnox> well. where do the vfs modules go?
21:28 < vorlon> obnox: vfs modules go under /usr/lib/samba, but those aren't libraries :)
21:29 < obnox> vorlon: with /usr/lib, you won't need to care about the shared lib search path, but you could add
               a file like /etc/ld.so.conf.d/samba.conf - would this be an option? on the other hand this lib
               would not conflict with any other package
21:29 < vorlon> obnox: I consider installing libs in paths other than /usr/lib an error and won't do that in any
                of my packages
21:30 < vorlon> obnox: if you add /etc/ld.so.conf.d/samba.conf anyway, all you're doing is declaring that they're
                part of a single namespace - so why use crude hacks like that to reunify the namespace when we
                can just as well install them into /usr/lib to begin with?
21:30 < vorlon> (thereby eliminating any chance of confusion from multiple libraries with conflicting names
                shadowing one another)
21:31 < obnox> vorlon: i would like to know why. see, I triggered the shared libs stuff (other than
               libsmbclient), so i would like to know how packagers like to handle this
21:31 < obnox> vorlon: ok.
21:33 < vorlon> obnox: if you install everything to /usr/lib, you have a great built-in tool to handle namespace
                collisions - the filesystem :)
21:33 < obnox> vorlon: so you think that the proper way is to put every library into already established lib
               paths and handle possible conflicts by package dependencies(/conflicts/provides...) ?
21:33 < vorlon> yes
21:34 < vorlon> indeed, if there *are* conflicts, that's probably an error, so we want to detect it
21:34 < obnox> ok. fair enough. and no hassling with LD_LIBRARY_PATH / RPATH / ld.so.conf ...
21:34 < vorlon> yes
21:43 < vorlon> obnox: rpath is also always a technically better solution than per-library ld.so.conf snippets,
                but Debian policy discourages use of rpath for other subtle reasons, so /usr/lib is it :)
21:45 < obnox> vorlon: it seems every that for every solution (except putting in /usr/lib) you find resources on
               the web detailing why this method is evil
21:45 < vorlon> obnox: most of them are probably right ;)
21:45 < obnox> :)
21:45 < vorlon> I mean, ok, separate paths for distro-managed vs. locally-installed libs, that's an important
                distinction to have
21:46 < obnox> sure
21:46 < vorlon> but people are always shooting themselves in the foot just with that, so having more directories
                is not a good thing :)

... and the discussion died there..:)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20080328/0a9d6252/attachment.pgp 


More information about the Pkg-samba-maint mailing list