PEP occurs, we will have to have multiple versions of pythons around
for months, if not years.
Jim Penny
>
>
> --
> Copyleft (c) 2001, Scott Moynes
tible version. Should package names be python1.5-popyda and
python-popyda?
---
Again, I have some reservations about breakage on a mass scale
when a new major of python comes out with this scheme, but I guess
paranoid maintainers can take care of that by routinely making an
equality depends in our packages.
Jim Penny
[EMAIL PROTECTED]
ys.
>
> Only "python" can provide "python-api-*".
>
Why? Could you better explain your reasoning here?
On the face of it, it certainly seems that python-1.5 ought to be
able to provide python-api-1.5.
Jim Penny
> Neil
>
>
> --
> To UNSUBSCRIBE,
date, well, at least they will have been put firmly
on notice of the deadline, with enough lead time to do something
about it.
Jim Penny
BTW: I have no feeling about dropping python-2.0; it appears that
portation from 2.0 to 2.1 is mostly very easy, and that there is no
strong reason to keep 2.0 in Debian.
On Tue, Dec 11, 2001 at 10:11:25PM +0100, Martin Michlmayr wrote:
> * Jim Penny <[EMAIL PROTECTED]> [20010425 15:07]:
> > zope-pythonmethod is essentially superceded by Script (python),
> > which entered zope as a non-optional component in release 2.3.
> >
> > Thi
Thinking about fog's reply:
was there an earlier python-egenix-mxdatetime compiled for 1.5?
I have
Package: python-egenix-mxdatetime
Version: 2.0.2-5
Depends: python (>= 2.1), python (<< 2.2), python2.1-egenix-mxdatetime
which is certainly not going to be compatible (or even findable) by
a zope1
ould guess no more than 2.5 Meg per version in total).
Jim Penny
>
> Jim Penny writes:
> > I have a zope 2.3 site. My best guess is that to upgrade it to
> > zope2.4 is going to be a three day (24 working hour) process. I
> > cannot just take it down for three days at my conv
tual testing under old or leading edge pythons. And if they have
not, the user contract is being violated. The packager may easily manage
to inadvertantly install a broken package!
Finally, the emacs compilation process is one reason that I make very
sure that no emacs packages are i
ction required for this scheme (something like tested
for: )? Presumbly conflicts can be used for state D.
For python scripts, can Recommends: be used to set the prefered
python? What if the preferred python is not installed?
Jim Penny
>
> On Fri, Feb 22, 2002 at 07:03:59PM -0500, Jim Penny wrote:
> > On Sat, Feb 23, 2002 at 10:38:17AM +1100, Donovan Baarda wrote:
> > > On Tue, Feb 12, 2002 at 12:05:22AM +0100, Bastian Kleineidam wrote:
> [...]
> > > Did you see my analysis and modified &q
On Sun, Feb 24, 2002 at 10:35:47AM +1100, Donovan Baarda wrote:
> On Sat, Feb 23, 2002 at 03:31:26PM -0500, Jim Penny wrote:
> >
> > > The python-central approach attempts to provide a single package that
> > > supports multiple versions of python.
> > >
>
rt and consider providing support for the experimental
> > python2.3 packages.
>
> Any reason to keep 2.1 ?
>
> Cheers,
Zope 2.5 does not run well on 2.2.
Zope 2.6 is supposed to run on 2.2, but 2.2 is not officially supported.
(and 2.6 is in the longest beta ever.)
Zope
ed, have an informal policy of "support everything in the
distribution", but do not have any obejection to supporting less!
Or, are you saying that you have non-debian applications that depend on
1.5?
Jim Penny
>
> Martin
g the -doc on your own system and
loading it up as a with Architecture: all.
This is impure, but pragmatic. It is impure because anyone else who
wants to build it will have to do so by hand. It is pragmatic because
the autobuilders won't have to build it (or anyone else, either).
Jim Penny
On Tue, 09 Sep 2003 21:27:16 +0200
Andreas Rottmann <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I wonder how long source packages that build binary packages for
> multiple versions (2.{1,2,3}) should continue to build packages for
> the old Python versions. IMHO, this should be documented somewhere
> (P
pe3 will require huge amounts of change --
but even 2.6 to 2.7 requires a good deal of administrative change, and
some substantive change.
Jim Penny
.1 as default. That cannot be
undone, it is released, and at the time the decision was made, 2.2 was
way too close to the cutting edge for comfort.
Moreover, we would not recommend that the target audience of
Python-in-a-Tie run sid. Sid breaks things occasionally, sometimes
badly. Sid tortures small defenseless things for a hobby!
2.2 is available in woody already. Invoke it using /usr/bin/python2.2.
BTW: is the PIAT consortium going to offer any DSFG free software?
Jim Penny
17 matches
Mail list logo
