brainstorming for UDS-N - Package Selection and Defaults

[Barry Warsaw]

On Oct 07, 2010, at 03:10 PM, Matthias Klose wrote:

>On 04.10.2010 02:30, Robert Collins wrote:
>> It would be really nice, as a 'runs unpackaged stuff on the distro'
>> use case, to support the highest python version on one LTS as a
>> non-default on the next LTS, consistently.
>
>No. why ship 2.6 with the next LTS? Why keep ~20MB on each CD which is not
>used?  If this is needed for developers, then you could provide something
>like this in a PPA, which is continuously updated.

I think the reason to have overlap in Python versions between LTS releases is
for the benefit of end users who have applications that are not in our
archive.  What I mean is that, yes, we can theoretically fix all the
compatibility problems for packages in main and universe, but we can do
nothing about third party applications and libraries that are not in our
archives.  These may be applications that our users have built or bought, have
installed and running on the current production Lucid machines.

We could support Python 2.6 in a PPA, but I actually think that will be much
more work for us.  It has the potential for containing every package in main
and universe.  Imagine Important Corporation X has a mission critical Python
application that is not yet ported to Python 2.7.  Their choices are

* Don't upgrade to the next LTS
* Request Python 2.6 compatible builds for dependencies in the official PPA
* Expend the resources to port their application to 2.7
* Forget packaging and build everything themselves

As an end user, none of those would be very appealing.

As a policy, I do think it makes sense for us to have one Python version
overlap between LTS releases.

New Python releases come out approximately every 18 months.  New LTS releases
come out usually every two years.  I'd be surprised if we ever get into a
situation where we'd jump a Python release (though the migration to Python 3
will make things interesting).

>> As it is users have to migrate *both* the platform and the
>> python-version of their code simultaneously, and this tends to be
>> tricky.
>
>I doubt that *users* care. More, this is the default behaviour for
>almost any shared library, there not something special about it.  But
>if you are supportive to add 3.2 to lucid, sure 3.2 will be supported
>in the next LTS. I do not intend to have four python version in the
>archive until the next release.

3.2 final is scheduled for January 2011.  The next LTS will probably be April
2012.  It's unlikely 3.3 will be released by then.  We have Python 3.1 in
Lucid, so this would mean supporting 3.1 and 3.2 in 12.04.  So that would mean
4 versions of Python until 12.04.  OTOH, I'm not convinced we should have the
same policy for Python 3 as we do for Python 2, yet.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20101007/f2c07241/attachment.pgp