Fw: [PROPOSAL] To retire autoconf for 4.1

[Jelmer Vernooij]

On Fri, May 24, 2013 at 09:58:56AM -0400, Simo wrote:
> On 05/24/2013 09:07 AM, Jelmer Vernooij wrote:
> >On Fri, May 24, 2013 at 08:30:10AM -0400, Simo wrote:
> >>On 05/24/2013 07:58 AM, yaberger at ca.ibm.com wrote:
> >>>http://wiki.python.org/moin/Python2orPython3
> >>>
> >>>I believe you're right, ie: when most major distributions will provide a
> >>>Python 3.x package in their repositories, Samba team should start working
> >>>on moving from Python 2.x to 3.x for Samba and Waf.
> >>>RHEL 6.4 is on 2.6.6
> >>>Debian 7 is on 2.7.3 but also have a package for Python 3.2.3
> >>At SambaXP I and Alexander started raising a concern about this.
> >>Fedora is starting to plan to move to Python 3, so we need to start
> >>thinking about moving samba as well.
> >When will Fedora drop support for Python 2.x? Just having the default changed
> >shouldn't be a problem, so long as Python2.x is still installable.
> It is not that simple. Samba now is in the business of providing
> bindings, that mean dependencies for other applications. It is very
> likely we'll have to build bindings for both 2.x and 3.x at the same
> time and make them parallel installable for a while. Otherwise it
> becomes a multipackage flag day where all of samba and all dependent
> packages need to switch at once.
Are there particular dependent packages you are referring to here?
What exactly do we promise external users can rely on? Just tdb and ldb?

We need to clarify what exactly external users can expect from our APIs
and changes to them. In 3.x the answer to this was just that everything in
"libsmbclient.h" was public, but with Python APIs in Samba 4 it's more
complicated.

> >>Unfortunately we cannot just make a full switch. Because there are
> >>distributions that will stay on Python 2.x for a long time, much
> >>longer than Fedora's support for Python 2.x presumably.
> >>
> >>So we should really look into what it will take to try to support
> >>both 2.x and 3.x especially for generated bindings as the binding
> >>interface, I am told, changes quite some fundamental things.
> >>
> >>A flag day where we switch fro 2 to 3 is highly unfeasible unless we
> >>also decide to drop support for all Enterprise Linux distributions
> >>and all other long term maintenance Unix flavors at the same time. I
> >>do not think that would be a wise choice.
> >I've tried to do support for both python2 and python3 with a few projects. It
> >requires ugly hacks that make the code less readable, is a major pain to keep
> >up and prone to regressions even for smaller projects. It would be
> >a nightmare for a project the size of Samba.
> Blame python developers, 2 -> 3 *will* be nasty and hard for a lot
> of projects, we are not alone.
I agree, see my other email. Python upstream has done a bad job
of managing this transition, and it shows in the number of packages
that have migrated so far. There is a chicken-egg problem; distributions won't
drop python2 until most packages have migrated to Python3, but packages won't
migrate while the rest of the ecosystem is still on Python 2.  

There is no urgency for Samba to migrate so long as Python 2 is widely
available. It would still be nice to - a less fragmented ecosystem 
is good for everybody, and there are some nice features in Python 3 - 
but we need to consider the associated costs as well.

> >What are the long term releases we should be worried about a year from now that
> >don't support Python3 yet? Debian oldstable and stable both have Python3, and
> >all LTS releases of Ubuntu that are still supported also have a version of
> >Python3.
> No RHEL so far has Python 3, but see above, even if RHEL has python
> 3 it wouldn't make a big difference we would still wan to build with
> python 2 due to the fact the samba bindings are now dependencies for
> other projects.
Is that a burden that should be with the upstream Samba project? 

Maintaining support for both versions takes (a significant chunk of) developer
resources that could be used for other things. 

Cheers,

Jelmer