Re: Future of python2.6 in Debian
Hi,
On Wed, Jun 06, 2012 at 10:27:39AM +0900, Arnaud Fontaine wrote:
> Toni Mueller <toni@debian.org> writes:
> >> +1. Time to retire Python 2.6. From Bernd's reply it sounds like
> >> the Zope upgrade needn't block this.
> >
> > please DON'T!
> >
> > I am a heavy Zope user, and, as others stated already, the Debian
> > packages for Zope are useless. Sorry to say it that way, but that's
> > what it is. This has nothing to do with the way the Zope packagers in
> > Debian work, just with a gross mismatch of release cycles.
>
> Could you please elaborate on that? It would be really useful to get
> some feedbacks from users actually ;-). Thanks.
the Zope packages are imho generally useless for actually running Zope
and Zope applications, for the following reasons (but I do not claim
completeness, nor attribute meaning to the order in which I present the
issues):
* The Debian release cycle and the Zope/Plone release cycle greatly
diverge. Typically, every Plone release requires a specific Zope
release, and cannot easily be run on a different Zope release, if at
all.
Eg. until not-so-long ago, Plone 3 was the thing to use, and it used
a Zope version that required Python 2.4. Since some time, it's Plone
4.[01] that requires Python 2.6. Only the still-in-beta Plone 4.2
even works with Python 2.7 (but 2.6 is still supported). On the Plone
list and IRC channel, you can still find frequent questions about how
to migrate from 3.x, or even 2.x, to 4.x (I am approaching this
problem by using virtual machines with suitable older versions of
Debian).
Several points made below are just illustrations of this problem.
* The same thing holds for many of the components in a Zope
application: Their versions are tied down with the release, and other
versions are typically not easy to use - usually, they break the
site. This even starts with distribute, where you have to have a
certain version, not necessarily that shipped with Debian.
* Upgrading heavily depends on the availability of third-party
products, of which there are many, many of which are not packaged for
Debian, or not possible to package for Debian with suitable effort.
Downgrading is generally not supported, and just impossible.
This contriutes to the divergence in release cycles. If you eg.
move an application, you have to minutely reconstruct the environment
on the target server. Going with the shipped packages with different
versions is usually impossible.
* Since versions required by Zope and Plone are often different from
those shipped with Debian, or any other operating system for that
matter, about the only sane way to run a Zope application is to use a
virtualenv, and you even have to create it using --no-site-packages
to be on the safe side (I've once forgotten to specify this, and
great havoc ensued).
* Deployment scenarios of Zope applications cannot reasonably be
anticipated in the package management. Not only are there many
different ways to do it, for a popular site, there is typically
also a three- or more-tier structure involved:
ZEO server - Zope server(s) - cache server(s) - front end reverse proxy
In additon to that, these components are often scattered over several
pieces of iron, and accompanied by things like supervisord to keep
things running. Since the cost of having a Zope site typically only
pays off if you have a certain minimum size, the field is dominated
by professional applications that have to be sized to handle some
kind of load.
I am unaware of a Debian way to deploy multi-machine, multi-component
applications.
* Debian Security, while generally doing a brave job, is generally too
slow for Zope/Plone. Although security problems have been thankfully
not very frequent, some high-risk problems have been found recently.
These forced users to patch within hours.
* You need to be able to run various versions of Zope + stuff in
parallel. Eg. for a Plone 4.0 site, you have to have different
versions for packages than for a Plone 4.1 site, and the packages for
Plone 4.2 will be different again. You can easily end up needing them
all in parallel. This does even pertain to zc.buildout - you need a
suitable version for your project, and if you have more than one
project, you may easily end up needing more versions of it.
As others said already, zc.buildout is the way to go in the Zope area,
and everything else is basically asking for trouble, intractable, and
unsupported by the community.
But having a solid Python + distribute + virtualenv stuff in the base
system, still "feels" much, much better than dragging a stock upstream
Python into the system, several times, then go with that what is shipped
upstream, and often seems to be abandoned (since they want everyone to
use the latest and greatest). The Unified Installer for Plone carries
their own version of Python along, but this package is intended for
beginners only, not really for production use.
Summary: I don't see how Debian can fix all these problems (and more) at
once, but suggest that there be good Python (the language interpreter +
stdlibs) packages in Debian, thus providing a robust and friendly
environment, and leave the rest to the application developers and users.
But I also have a question. You wrote:
> Could you please elaborate on that? It would be really useful to get
> some feedbacks from users actually ;-). Thanks.
This suggests to me that you too are not users of these packages? If so,
why aren't you using them? Or if I misread you, and you are a user of
these packages, how do you cope with the problems outlined above?
Kind regards,
--Toni++
Reply to: