Fw: [PROPOSAL] To retire autoconf for 4.1

[David Collier-Brown]

On 05/24/2013 10:48 AM, Jelmer Vernooij wrote:
> 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
>
I can't help with maintaining two versions, but I have a toolset for
human-mediated automatic API changing, described briefly at
http://www.datacenterworks.com/stories/port.html

If the differences are well-known or perhaps even documented (:-)) we
can create a port database for them.

--dave

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain
(416) 223-8968