Re: Python 2.0.1; transition plans for woody

[Bruce Sass]

On Mon, 25 Jun 2001, Gregor Hoffleit wrote:
> On Mon, Jun 25, 2001 at 05:37:36PM +0200, Radovan Garabik wrote:
> > I agree, but... why not wait until python 2.1.1 is released?
> > (or, if we just discuss things a bit, it will be
> > released before any action is taken and we can jump right
> > to it :-))
> >
> > You still need to modify packages when going from
> > 2.0.1 to 2.1.1
>
> I'm afraid that if we wait for 2.1.1, it will be to late to make the
> complete transition for woody.

2.1.1 is expected in a month, Woody's freeze is ~2 months away(?)

is that correct?

> You're right, though, that with the current setup of the packages, 2.1.1
> again will make a small transition necessary.
>
> We have to discuss the policy of dependencies and paths for the Python
> packages at some point.

Would it not be easier if it was always a python--base that
provided "python"; packages would either depend on the version of
Python they need, or just "python" if it didn't matter.  Getting the
various Python's to co-exist isn't a problem, but trying to rotate
them through package name changes seems to be... so why do it.

Can this be done...
- install stuff into the dir of the Python it depends on; you would
  have a "python" libs dir for each installed version of Python,
  and one for the packages that don't care which Python runs them.
- separate the .py and .pyc|o files
- have each python executable that lives outside of a lib dir use
#!/usr/bin/env python
  or
#!/usr/bin/env python.

  depending on what the package the file came from has in
  its Depends: line.
?

...and which problems would it not solve?


- Bruce

Re: Python 2.0.1; transition plans for woody

[Harry Henry Gebel]

On Mon, Jun 25, 2001 at 04:02:05PM -0400, Harry Henry Gebel wrote:
> On Mon, Jun 25, 2001 at 04:36:28PM +0200, Gregor Hoffleit wrote:
> 
> I vote to change over, the sooner the better.

That was me not Gregor, sorry about that.

-- 
Harry Henry Gebel
West Dover Hundred, Delaware
GPG encrypted email gladly accepted. Key ID: B853FFFE
Fingerprint: 15A6 F58D AEED 5680 B41A  61FE 5A5F BB51 B853 FFFE


pgp8rer5BIt7Y.pgp
Description: PGP signature

Re: Python 2.0.1; transition plans for woody

[Harry Henry Gebel]

On Mon, Jun 25, 2001 at 04:36:28PM +0200, Gregor Hoffleit wrote:

I vote to change over, the sooner the better.

-- 
Harry Henry Gebel
West Dover Hundred, Delaware
GPG encrypted email gladly accepted. Key ID: B853FFFE
Fingerprint: 15A6 F58D AEED 5680 B41A  61FE 5A5F BB51 B853 FFFE


pgp4n18tJ6f9G.pgp
Description: PGP signature

Re: Python 2.0.1; transition plans for woody

[Radovan Garabik]

On Mon, Jun 25, 2001 at 05:50:01PM +0200, Gregor Hoffleit wrote:
> On Mon, Jun 25, 2001 at 05:42:30PM +0200, Radovan Garabik wrote:
> > > 
> > 
> > well, some time ago I symlinked some modules from python1.5 to python2.0
> > (binary ones) and surprisingly they worked (python just printed warning
> > message about incompatible API)
> 
> That's interesting, I never tried that. Indeed, it seems to work.
> 
> I'm not yet clear whether this is a good or a bad thing.

it is a VERY BAD thing. Just take any GPLed module and ask Stallman what
he thinks about running it with 2.0 


-- 
 ---
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

Re: Python 2.0.1; transition plans for woody

[Matthias Klose]

Gregor Hoffleit writes:
 > On Mon, Jun 25, 2001 at 05:37:36PM +0200, Radovan Garabik wrote:
 > > I agree, but... why not wait until python 2.1.1 is released?
 > > (or, if we just discuss things a bit, it will be
 > > released before any action is taken and we can jump right
 > > to it :-))

sure, the Debian python world moves slooowly ;-)

 > > 
 > > You still need to modify packages when going from
 > > 2.0.1 to 2.1.1
 > 
 > I'm afraid that if we wait for 2.1.1, it will be to late to make the
 > complete transition for woody.

Why are you afraid, that it's too late? You don't know the 2.1.1
release date. Any the Debian boot floppies aren't ready too.

 > You're right, though, that with the current setup of the packages, 2.1.1
 > again will make a small transition necessary.

I would prefer to make this second transition obsolete.

- Is it possible to ask upstream for a checkin of the changed policy
  in the CVS?

- If we assume the same release speed for woody as seen for our
  previous releases, then it's VERY likely that 2.1.1 is release before
  woody.
  You are right that a transition from 2.0 to 2.1 at this point is
  unlikely for woody. Therefore I propose to upgrade to 2.1 now and
  upgrade to 2.1.1 during the woody release process.

PLEASE evaluate these options!

If 2.0 becomes the default python version for woody, then make
(probably non-free) 2.1 available for woody. There are many packages
that won't retain source compatibility to 2.0.

I fear when woody is released we'll have a stable outdated python
version for which it becomes difficult to build newer third party
packages ...

Matthias

 > We have to discuss the policy of dependencies and paths for the Python
 > packages at some point.

and don't forget the Debian python policy ...

Re: Python 2.0.1; transition plans for woody

[Neil Schemenauer]

Gregor Hoffleit wrote:
> IMHO this is the point where we should make a big step, and enforce a quick
> transition of the archive to Python 2.0.1.

Yes please.  Packages named python suck.  I'm willing to work on
rebuilding packages or whatever else needs to be done.

  Neil

Re: Python 2.0.1; transition plans for woody

[Mikael Hedin]

Please go ahead!  The fewer nameX type packages the better.

Should be no problems for plucker (=me)

/Micce
-- 
Mikael Hedin, MSc   +46 (0)980 79176
Swedish Institute of Space Physics  +46 (0)8 344979 (home)
Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile)
[gpg key fingerprint = 387F A8DB DC2A 50E3 FE26  30C4 5793 29D3 C01B 2A22]

Re: Python 2.0.1; transition plans for woody

[Gregor Hoffleit]

On Mon, Jun 25, 2001 at 05:42:30PM +0200, Radovan Garabik wrote:
> On Mon, Jun 25, 2001 at 05:21:39PM +0200, Gregor Hoffleit wrote:
> > 
> > With the default setup, stuff in /usr/lib/python1.5/site-packages would be
> > ignored by 2.0.1. In order to make the transition easier, we might decide
> > to append /usr/lib/python1.5/site-packages to the sys.path, though:
> > 
> > Almost all pure Python modules that are currently installed in the
> > python1.5 directory will work with 2.0.1; Python 2.0.1 is almost completely
> > backwards compatible, and one might consider all remaining problems bugs in
> > the potato packages.
> > 
> > Binary modules in /usr/lib/python1.5/site-packages won't work.
> > 
> 
> well, some time ago I symlinked some modules from python1.5 to python2.0
> (binary ones) and surprisingly they worked (python just printed warning
> message about incompatible API)

That's interesting, I never tried that. Indeed, it seems to work.

I'm not yet clear whether this is a good or a bad thing.

Gregor

Re: Python 2.0.1; transition plans for woody

[Gregor Hoffleit]

On Mon, Jun 25, 2001 at 05:37:36PM +0200, Radovan Garabik wrote:
> I agree, but... why not wait until python 2.1.1 is released?
> (or, if we just discuss things a bit, it will be
> released before any action is taken and we can jump right
> to it :-))
> 
> You still need to modify packages when going from
> 2.0.1 to 2.1.1

I'm afraid that if we wait for 2.1.1, it will be to late to make the
complete transition for woody.

You're right, though, that with the current setup of the packages, 2.1.1
again will make a small transition necessary.

We have to discuss the policy of dependencies and paths for the Python
packages at some point.

Gregor

Re: Python 2.0.1; transition plans for woody

[Radovan Garabik]

On Mon, Jun 25, 2001 at 05:21:39PM +0200, Gregor Hoffleit wrote:
> 
> With the default setup, stuff in /usr/lib/python1.5/site-packages would be
> ignored by 2.0.1. In order to make the transition easier, we might decide to
> append /usr/lib/python1.5/site-packages to the sys.path, though:
> 
> Almost all pure Python modules that are currently installed in the python1.5
> directory will work with 2.0.1; Python 2.0.1 is almost completely backwards
> compatible, and one might consider all remaining problems bugs in the potato
> packages.
> 
> Binary modules in /usr/lib/python1.5/site-packages won't work.
> 

well, some time ago I symlinked some modules from python1.5 to python2.0
(binary ones) and surprisingly they worked (python just printed warning message
about incompatible API)

 

-- 
 ---
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

Re: Python 2.0.1; transition plans for woody

[Radovan Garabik]

On Mon, Jun 25, 2001 at 04:36:28PM +0200, Gregor Hoffleit wrote:
> Hi,
...

> 
> This would mean that I upload new versions of the Python packages:
> 
>   (1) python2 (python2-base etc.) would be removed
> 
>   (2) python 2.0.1-1 (python-base etc.) would replace python 1.5.2-16
> 
>   (3) A new set of legacy packages python15 (python152 ???) for those who
>   think that they depend on the old version 1.5.2.
> 

...

> 
> 
> What do you think ?
> 

I agree, but... why not wait until python 2.1.1 is released?
(or, if we just discuss things a bit, it will be
released before any action is taken and we can jump right
to it :-))

You still need to modify packages when going from
2.0.1 to 2.1.1

-- 
 ---
| Radovan Garabik http://melkor.dnp.fmph.uniba.sk/~garabik/ |
| __..--^^^--..__garabik @ melkor.dnp.fmph.uniba.sk |
 ---
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!

Re: Python 2.0.1; transition plans for woody

[Gregor Hoffleit]

On Tue, Jun 26, 2001 at 12:47:28AM +1000, Anthony Towns wrote:
> On Mon, Jun 25, 2001 at 04:36:28PM +0200, Gregor Hoffleit wrote:
> > This would mean that I upload new versions of the Python packages:
> >   (1) python2 (python2-base etc.) would be removed
> >   (2) python 2.0.1-1 (python-base etc.) would replace python 1.5.2-16
> >   (3) A new set of legacy packages python15 (python152 ???) for those who
> >   think that they depend on the old version 1.5.2.
> > The transition would not be simple, though.
> 
> How does this affect upgrades?
> 
> Will potato packages that depend on python work with python 2.0.1 packages
> in general? What about ones that put stuff in /usr/lib/python1.5? If not,
> what will you do to ensure partial upgrades work correctly? If so, that may
> give us an easy out for transitioning the python2 packages.


We have an option here:

With the default setup, stuff in /usr/lib/python1.5/site-packages would be
ignored by 2.0.1. In order to make the transition easier, we might decide to
append /usr/lib/python1.5/site-packages to the sys.path, though:

Almost all pure Python modules that are currently installed in the python1.5
directory will work with 2.0.1; Python 2.0.1 is almost completely backwards
compatible, and one might consider all remaining problems bugs in the potato
packages.

Binary modules in /usr/lib/python1.5/site-packages won't work.


> > Nearly all Python packages (to be exact: those who install things in
> > /usr/lib/python1.5, those who build binary extension modules, and those who
> > link with libpython1.5) would have to be modified and rebuilt. Those
> > packages that provide both python2-* and python-* versions would have to be
> > modified to instead build python-* and python15-* versions; the dependencies
> > of those packages would need closer inspection.
> 
> There are only a dozen or so packages in unstable/i386 that have versioned
> depends on python2 related stuff; anything else should be able to be
> handled with provides:.

IMHO that's the most pressing problem, and has to be inspected carefully:

Packages that have unversioned depends on python or python-base, but do in
fact depend on Python 1.5.2. They would break after an upgrade to 


> > What do you think ?
> 
> If you can make upgrades work; if you can not break too many
> people's testing or unstable systems; and if you can get everything
> rewritten/rebuilt relatively quickly, I'd say it's worth doing.


A first try at an transition plan:

(1) I upload python 2.0.1-1. python-base 2.0.1-1 provides 'python', 'python2'
and 'python2-base'. /usr/lib/python1.5/site-packages will be appended to the
sys.path. A bug will be filed against the archive to remove the python2
package.

Most 'python-*' packages will continue to work in this setup. python2-*
packages should continue to work as well. python-* Packages with binary
extension modules will break.

(2) python-* packages that broke should be rebuilt against the Python 2.0.1
package as fast as possible. Aggressive NMUs should be allowed here after a
few days.

(3) Bugs should be filed against all remaining packages that install stuff
in /usr/lib/python1.5. They should be rebuilt against Python 2.0.1. Finally,
no woody package should install stuff in /usr/lib/python1.5.


I'm pretty sure that I miss some crucial points with this plan, though.
Please correct me where due.


My impression is that during a transition period, unstable's Python packages
will be quite unstable. Still, rebuilding the packages should be a very
simple thing in most cases, so the only crucial thing is that either
maintainer act quickly, or we're going on NMU aggressively.


One remaining problem is how to handle partial upgrades of a potato system:
To handle this well, python-base 2.0.1-1 would have to include a list of
conflicts against all potato packages that won't work with the new python
packages (I guess in the end that's about a dozen packages).


Gregor

Re: Python 2.0.1; transition plans for woody

[Federico Di Gregorio]

On 26 Jun 2001 00:47:28 +1000, Anthony Towns wrote:
[snip]
> If you can make upgrades work; if you can not break too many
> people's testing or unstable systems; and if you can get everything
> rewritten/rebuilt relatively quickly, I'd say it's worth doing.

err.. em.. unstable systems are there to be broken. if a lot of people
outside debian development use unstable on production machine, that is
their fault. (well, partly. even with testing debian is way too slow to
release, imho.)

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology  [EMAIL PROTECTED]
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
 A short story: I want you. I love you. I'll miss you. -- Me

Re: Python 2.0.1; transition plans for woody

[Anthony Towns]

On Mon, Jun 25, 2001 at 04:36:28PM +0200, Gregor Hoffleit wrote:
> This would mean that I upload new versions of the Python packages:
>   (1) python2 (python2-base etc.) would be removed
>   (2) python 2.0.1-1 (python-base etc.) would replace python 1.5.2-16
>   (3) A new set of legacy packages python15 (python152 ???) for those who
>   think that they depend on the old version 1.5.2.
> The transition would not be simple, though.

How does this affect upgrades?

Will potato packages that depend on python work with python 2.0.1 packages
in general? What about ones that put stuff in /usr/lib/python1.5? If not,
what will you do to ensure partial upgrades work correctly? If so, that may
give us an easy out for transitioning the python2 packages.

> Nearly all Python packages (to be exact: those who install things in
> /usr/lib/python1.5, those who build binary extension modules, and those who
> link with libpython1.5) would have to be modified and rebuilt. Those
> packages that provide both python2-* and python-* versions would have to be
> modified to instead build python-* and python15-* versions; the dependencies
> of those packages would need closer inspection.

There are only a dozen or so packages in unstable/i386 that have versioned
depends on python2 related stuff; anything else should be able to be
handled with provides:.

> What do you think ?

If you can make upgrades work; if you can not break too many
people's testing or unstable systems; and if you can get everything
rewritten/rebuilt relatively quickly, I'd say it's worth doing.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)

Re: Python 2.0.1; transition plans for woody

[Federico Di Gregorio]

On 25 Jun 2001 16:36:28 +0200, Gregor Hoffleit wrote:
[tech stuff snipped]
> Still I think it is much preferable to make this transition before the
> release of woody; when we release woody with python2-* packages this will be
> a big unnecessary burden for the next release; when we make the migration
> now, only people who are using unstable might be hurt during the transition
> process.
> 
> 
> What do you think ?

agreed. gpl compatible 2.0 in woody would be *really nice*. lets do it
now. before othe people (usually not maintaining any python package)
start comlaining ;-)

ciao,
federico 

-- 
Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology  [EMAIL PROTECTED]
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
   God is real. Unless declared integer. -- Anonymous FORTRAN programmer

Re: Python 2.0.1; transition plans for woody

[Joseph Carter]

On Mon, Jun 25, 2001 at 04:36:28PM +0200, Gregor Hoffleit wrote:
>   (3) A new set of legacy packages python15 (python152 ???) for those who
>   think that they depend on the old version 1.5.2.

I wouldn't even bother with that, if everything C needs recompiling
anyway, just recompile for 2.0 only and be done with it.

-- 
Joseph Carter <[EMAIL PROTECTED]>   Free software developer

 but, then I used an Atari, I was more likely to win the lottery in ten
countries simultaneously than get accelerated X



pgpuyFqFdm5rr.pgp
Description: PGP signature

Python 2.0.1; transition plans for woody

[Gregor Hoffleit]

Hi,

Python 2.0.1 is out, finally with a GPL compatible license. Zope 2.3.3 works
fine with Python 2.0; I'm not aware of any problems with Debian packages
wrt. Python 2.x. That nullifies all reasons for the existance of dual Python
packages in Debian (cf. /usr/share/doc/python2/README.why-python2)

IMHO this is the point where we should make a big step, and enforce a quick
transition of the archive to Python 2.0.1.


This would mean that I upload new versions of the Python packages:

  (1) python2 (python2-base etc.) would be removed

  (2) python 2.0.1-1 (python-base etc.) would replace python 1.5.2-16

  (3) A new set of legacy packages python15 (python152 ???) for those who
  think that they depend on the old version 1.5.2.

  
The transition would not be simple, though.

Nearly all Python packages (to be exact: those who install things in
/usr/lib/python1.5, those who build binary extension modules, and those who
link with libpython1.5) would have to be modified and rebuilt. Those
packages that provide both python2-* and python-* versions would have to be
modified to instead build python-* and python15-* versions; the dependencies
of those packages would need closer inspection.

Still I think it is much preferable to make this transition before the
release of woody; when we release woody with python2-* packages this will be
a big unnecessary burden for the next release; when we make the migration
now, only people who are using unstable might be hurt during the transition
process.


What do you think ?

Gregor