The Wrapper Project
asn at samba.org
Fri Nov 29 02:34:17 MST 2013
On Friday 29 November 2013 00:38:23 Jelmer Vernooij wrote:
> On Thu, Nov 28, 2013 at 05:22:35PM +0100, Andreas Schneider wrote:
> > On Thursday 28 November 2013 06:17:19 Andrew Bartlett wrote:
> > > One of the oddities of Samba is that we don't do that very much at all.
> > > We are very hesitant to rely on external free software projects, for
> > > better or worse.
> > So on day we will add glibc to our tree? :)
> Obviously we don't want to do that, but we go through a lot of trouble
> to work around defects in the system libc; libreplace is a testament
> to that.
> > > I would want to ensure we had a very strict rule as to
> > >
> > > exactly the version of these wrappers that we used against a specific
> > > version of Samba. I think bundling these like we do popt et al is the
> > > best approach for now.
> > Why are you (an others) always come up with these lame excuses. Why don't
> > you just admit that you are lazy and don't want to install any of the
> > 3rdparty software.
> Thanks for keeping the discussion constructive.
> I can't speak to Andrew's specific experiences here, but I've had
> similar experiences in other projects. You're introducing more moving
> parts. If I hit a strange bug running "make test", I don't want to
> have to worry about whether I'm running the latest revision
> of nss_wrapper, socket_wrapper, etc in which a relevant bug might
> be fixed.
> Having to install extra dependencies raises the bar for hacking on
> Samba, and it makes things more complex for the buildfarm. That
> cost can be justified in some cases, but adding three extra
> dependencies to just avoid shipping ~10k LOC is not worth it.
Thanks, that is what I wanted to hear and not other lame excuses.
> > Last heimdal update: July 2011 (Heimdal last release was done 2012-01-11)
> > Quick copy: 68 files changed, 6750 insertions(+), 3142 deletions(-)
> > Last zlib update: before 2008 (moved to lib/ in 2008)
> > Last iniparser update: before 2010 (moved to lib/ in 2010)
> > Last popt update: before 2010 (moved to lib/ in 2010)
> If we're going to start depending on external software and no longer
> shipping a bundled copy, then let's start with more widely available and
> mature libraries like zlib or popt.
I don't know the Debian policy but for RPM base distribution especially
enterprise it is a requirement to always build against the system library. So
it is important that the code works against the system library. If you fix a
bug in a bundled library who takes care that these are fixed in the upstream
project? From the commits I guess a lot of them are only in our tree. And I'm
not sure Covertiy fixes get contributed back.
> I don't see why the update dates for these bundled libraries are
> problematic here. At least these copies we can update if we want/need
> to. If we start relying on the system copies then we'll encounter
> users with much older versions.
As long as the bundled libraries are only used for hacking on Samba it is
fine. I think it is problematic to build a samba package and ship it to others
with the bundled version cause we obviously do not keep them in sync to get
Andreas Schneider GPG-ID: CC014E3D
Samba Team asn at samba.org
More information about the samba-technical