[RFC] Switch on tdb2 API by default?

Dan Shearer dan at shearer.org
Thu Sep 29 11:40:54 MDT 2011

On Thu, Sep 29, 2011 at 07:52:48AM -0700, Kai Blin wrote:
> On 2011-09-29 02:40, Dan Shearer wrote:
> > The Python team says "Python runs everywhere". That's their goal. So it
> > makes sense to me to push autoconf maintenance on weird/horrible
> > platforms off to the Python team.
> The Python team did end-of-life python2, though, and Samba doesn't work
> with python3. 

Yes, there will be work either way (I cited Python 3 for size
indications, sorry, basically rampant growth isn't an issue.) But
end-of-lifing Python2 is really unlikely to break the build system on
Unix where it's working now.  I don't have regular access to AIX so I
just can't remember precisely, but Solaris and HP-UX Python2 builds
worked for me relatively recently. Noting that if you go back two major
versions of Solaris or HP-UX you can't compile Samba or anything serious
without adding replacement libraries so there's limits on Volker's
out-of-the-box requirement.

> This causes all sorts of pain on ArchLinux already, where
> they are bleeding edge enough to make "python" point to python3 and
> break our build system.

Python versioning has often been a pain (remember 2.4 on various
distros?) and I expect we're coming up for another big migration muddle.
But none of that applies to ancient old Unix, where if Python compiles,
we're good.

Do you really see Python2 builds breaking on old Unix if they work

> Also, to the point of "Python runs everywhere", Python is a pain to
> cross-compile, and it's a pain to get working on less common C
> libraries. 

Samba3 has often been a pain to cross-compile, and we don't have any
supported cross-compiled platforms do we?  The small targets scare me,
every time I try there's another bit missing or changed. 

Come to think of it that's probably the point: the small targets tend to
evolve quite fast, and Volker is talking about targets that change very

I don't have an answer to the cross compile question. Didn't think of

But it seems to me that keeping a non-fancy build of Python working on
the architectures Volker is talking about is not such a big deal, and
the Python team are likely to regard build failures as bugs they care
about. That's why they have a buildbot service. Is that a reasonable

> Bionic comes to mind. I know there's a Python out there for
> Android somewhere, but last I tried it wasn't trivial to compile python
> for that platform. Seeing how there's a Samba3 build for Android and no
> Samba4 build so far, maybe there is a difference.

You've got me here, I've no idea how to handle the little, fast-moving
platforms without autoconf. Personally I really want Python to work on
Android and so far I have completely failed.  Bionic is horrible. 
> > Python source was compilation time, would that be acceptable? I can't
> > recall Python requiring anything other than standard tools on Solaris,
> > HP-UX and (most likely) AIX. The good thing about these platforms is
> > that they don't change much. And we don't even have to build a Python
> > with all features enabled.
> Volker may argue about the high-end big iron, I'm more concerned about
> the low end embedded systems. For those you could probably compile
> Python natively and it'd work, but usually you'd want to cross-compile
> software for it. I haven't been able to cross-compile Python when I
> tried to do so.

I really don't know about those systems.

But getting back to the big iron problem, would offering
samba-4-with-python-included.tar.bz2 be a good enough way of addressing
it? A prerequisite would be contacting the Python buildbot team and helping
them add some buildslave hosts, but at least it would be a strategy. 

> Note that as build systems go I tend to prefer waf to autoconf because I
> know Python much better than m4. But I do get Volker's point that it's
> not as portable as the autoconf build system.

The point about big iron is maintainability over decades, because these
things last forever in big companies. So here's my question to you:
which sounds like the smaller problem space: maintaining autoconf in
Samba for decades or keeping trailing-edge CPython building for decades?
I reckon its the latter.

Dan Shearer
dan at shearer.org

More information about the samba-technical mailing list