Removal of python1.5?
Matthias Klose
packages remaining:
- pydb: http://bugs.debian.org/119203
Not yet ported to 2.1, but we do have an alterbate debugger
available (idle).
- python-pam: http://bugs.debian.org/119213
See http://ftp-master.debian.org/~doko/python for a try.
However I couldn't get it reliably working ...
- python1.5-distutils: Included in python1.5.
All other python1.5 dependent packages are either:
- modules, which are built for python2.1 as well. So it seems to be
safe to remove them. It's not necessary to file bugs to
ftp.debian.org, simply do not build the module from the (same) source
package from which you build your 2.1 module.
- or packages, which depend on: python1.5 | python2.1. Drop the
reference to python1.5 (and python2).
These packages are:
- pychecker
- python-pqueue
- python-egenix-mxbase
- python1.5-imaging
- python1.5-psycopg
If I don't hear a serious reason to keep python1.5, I plan to file a
bug report for ftp.debian.org to remove the python1.5 package.
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jérôme Marant
> It looks like the move to python (v2.1) is done. There are three
> packages remaining:
...
> These packages are:
>
> - pychecker
> - python-pqueue
> - python-egenix-mxbase
> - python1.5-imaging
> - python1.5-psycopg
I've also seen python1.5-orbit in incoming.
>
> If I don't hear a serious reason to keep python1.5, I plan to file a
> bug report for ftp.debian.org to remove the python1.5 package.
Me neither. But better make sure first that noone need 1.5 any more.
--
Jérôme Marant <jerome...@free.fr>
<jer...@marant.org>
Radovan Garabik
> Matthias Klose <do...@cs.tu-berlin.de> writes:
>
> > It looks like the move to python (v2.1) is done. There are three
> > packages remaining:
> > These packages are:
> >
> > - pychecker
> > - python-pqueue
> > - python-egenix-mxbase
> > - python1.5-imaging
> > - python1.5-psycopg
>
>
> >
> > bug report for ftp.debian.org to remove the python1.5 package.
>
There is also xtalk that fails to work with newer python,
but so far I have not gotten around to uploading new version
with correct dependencies (it time permits, I'd rather
try to fix the program itself)
--
-----------------------------------------------------------
| 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!
Mikhail Sobolev
> - python-pam: http://bugs.debian.org/119213
> See http://ftp-master.debian.org/~doko/python for a try.
> However I couldn't get it reliably working ...
Could you please give more details on this? I do use this package and would
like to know what I should expect...
--
Misha
Matthias Klose
> On Sun, Dec 09, 2001 at 08:00:20PM +0100, Matthias Klose wrote:
> | packages remaining:
>
> upstream (last release in '98). The testsuite passes for 2.1 but not
> 2.2. Both versions give deprecation warnings about using the 'regex'
> and 'resub' modules.
gadfly has been converted to 2.1.
Anthony Towns
> bug report for ftp.debian.org to remove the python1.5 package.
Eh?
python1.5's still useful to users, isn't it, especially ones with
important python programs they don't want to port to 2.1 just yet?
Dropping python1.5 doesn't seem a particularly clever thing to do.
Cheers,
aj
--
Anthony Towns <a...@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
"Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
see http://azure.humbug.org.au/~aj/armadillos.txt
dman
| On Sun, Dec 09, 2001 at 08:00:20PM +0100, Matthias Klose wrote:
| > bug report for ftp.debian.org to remove the python1.5 package.
|
|
| python1.5's still useful to users, isn't it, especially ones with
| important python programs they don't want to port to 2.1 just yet?
I suppose it could be.
FWIW since I just installed the new gadfly package, removing
python1.5-base didn't try and remove anything else. I now have just
2.1 and 2.2 on my system.
-D
--
A wise servant will rule over a disgraceful son,
and will share the inheritance as one of the brothers.
Proverbs 17:2
Matthias Klose
> On Mon, Dec 10, 2001 at 11:53:24AM +1000, Anthony Towns wrote:
> > On Sun, Dec 09, 2001 at 08:00:20PM +0100, Matthias Klose wrote:
> > > If I don't hear a serious reason to keep python1.5, I plan to file a
> > > bug report for ftp.debian.org to remove the python1.5 package.
> >
> > Eh?
> >
> > python1.5's still useful to users, isn't it, especially ones with
> > important python programs they don't want to port to 2.1 just yet?
> >
>
> compatability of scripts etc.
hmm, yes, this argument holds for all versions of all packages ...
> Now that the python policy supports multiple versions and a default version,
> having old versions around doesn't hurt. Why not just leave them there?
> Removing them buys nothing but a little archive space.
well, but the policy shouldn't be used to rectify a Debian python
museum.
Chris Lawrence
> Donovan Baarda writes:
> > On Mon, Dec 10, 2001 at 11:53:24AM +1000, Anthony Towns wrote:
> > > On Sun, Dec 09, 2001 at 08:00:20PM +0100, Matthias Klose wrote:
> > > > bug report for ftp.debian.org to remove the python1.5 package.
> > >
> > >
> > > python1.5's still useful to users, isn't it, especially ones with
> > > important python programs they don't want to port to 2.1 just yet?
> > >
> > > Dropping python1.5 doesn't seem a particularly clever thing to do.
> >
> > I agree. Old versions can also be useful when testing backwards
> > compatability of scripts etc.
>
> hmm, yes, this argument holds for all versions of all packages ...
>
> > Now that the python policy supports multiple versions and a default version,
> > having old versions around doesn't hurt. Why not just leave them there?
> > Removing them buys nothing but a little archive space.
>
> well, but the policy shouldn't be used to rectify a Debian python
> museum.
IMHO keeping Python 1.5 around for woody doesn't hurt anything.
People could still have legacy scripts that need Python 1.5 that
aren't accounted for by Debian packages, for example. Also, the 1.5
packages in potato are incompatible with the current Python packaging;
if someone needs 1.5 on a woody box, and we drop it from woody, they'd
have to build from source and debianize it themselves or install into
/usr/local.
Now, after woody is released, I can't see any good reason to keep 1.5
around for woody+1. But for now let's keep it around. (If you or
Gregor don't want to maintain it, someone else would probably volunteer.)
Chris
--
Chris Lawrence <ch...@lordsutch.com> - http://www.lordsutch.com/chris/
Roland Mas
> Matthias Klose <do...@cs.tu-berlin.de> writes:
>
>> It looks like the move to python (v2.1) is done. There are three
>> packages remaining:
> ...
>> These packages are:
>>
>> - pychecker
>> - python-pqueue
>> - python-egenix-mxbase
>> - python1.5-imaging
>> - python1.5-psycopg
>
> I've also seen python1.5-orbit in incoming.
I've asked for the removal of the python1.5-orbit source package a few
days ago, and it was removed. The one you saw in incoming was
probably one of the binaries built from the python-orbit source
package (from which the module is built for python 1.5, 2.1 and 2.2).
I am still not sure it's a good thing to remove Python 1.5.
Roland.
--
Roland Mas
You can't second-guess ineffability, I always say.
-- Aziraphale, in Good Omens (Terry Pratchett and Neil Gaiman)
Anthony Towns
> Anthony Towns writes:
> > python1.5's still useful to users, isn't it, especially ones with
> > important python programs
> and python-pam. I do not count pydb, because a debugger for the old
> version alone doesn't make sense.
I mean for people who haven't managed to port their *own* (unpackaged) apps
to python 2.x.
Considering this list just went through convincing me that this *wasn't*
a trivial matter, I hope you're not going to go changing your minds on me
now.
Also, if python1.5's dropped from woody+1, then people who want it are
at least able to get it from woody; if it's dropped from woody they
can't get it from potato.
> > they don't want to port to 2.1 just yet?
> where "yet" is greater than about a year ..., and compared to python2
> much longer.
We didn't port to 2.1 until just now. Don't see why we should expect
everyone else to have done so already.
Jim Penny
> On Mon, Dec 10, 2001 at 07:22:36AM +0100, Matthias Klose wrote:
> > Anthony Towns writes:
> > > python1.5's still useful to users, isn't it, especially ones with
> > > important python programs
> > that was the precondition for the removal. Currently there are xtalk
> > and python-pam. I do not count pydb, because a debugger for the old
> > version alone doesn't make sense.
>
> I mean for people who haven't managed to port their *own* (unpackaged) apps
> to python 2.x.
>
> Considering this list just went through convincing me that this *wasn't*
> a trivial matter, I hope you're not going to go changing your minds on me
> now.
For what its worth, probably very little, I agree with aj. 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 convenience. This will have to wait until there is
a plant shutdown.
I suspect that anyone who has a lot of labor invested in zope 2.3 is in
a similar circumstance. I am not sure that the upgrade process has been,
nor even can be, fully automated; particularly if the user still has
the older pythonscripts, rather than the Script (Python).
For similar reasons, I can see someone beginning a migration to zope 2.4
and then having to backtrack to 2.3 to get the site back on-line fast
enough. In fact, I would have been far more comfortable had zope been
versioned, so that both a 2.3 and a 2.4 could exist concurrently. This
would make site migration far easier, as the older site could be peeled
off folder by folder and tested that way, with less fear of major
disruption.
If we are to argue that python is "mission critical" and that "mission
critical applications" are to be built on it; then we have to behave
that way. And one implication of this is that we have to be very
conservative in dropping old major releases. A two year lead time
notice seems not at all unreasonable. That is, put a prominent notice
that the package will be withdrawn two years from now. Put in in both
the Debian README, and in the python-doc front page.
Then, if someone comes back whining that their application no longer
works after that 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.
Tille, Andreas
> For what its worth, probably very little, I agree with aj. I have a
> zope 2.3 site.
If I'm not completely wrong Zope 2.3 runs perfectly with Python 2.1.
So at least this is no reason to keep Python 1.5. (I'm not talking
about other things - just regarding to Zope 2.3.)
> 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 convenience. This will have to wait until there is
> a plant shutdown.
>
> I suspect that anyone who has a lot of labor invested in zope 2.3 is in
> a similar circumstance. I am not sure that the upgrade process has been,
> nor even can be, fully automated; particularly if the user still has
> the older pythonscripts, rather than the Script (Python).
I fully understand your reasoning. But what about copying your Zope
application and starting a test how expensive the upgrade would be? Just
a thought. ANother thought would be asking on the Zope lists...
> For similar reasons, I can see someone beginning a migration to zope 2.4
> and then having to backtrack to 2.3 to get the site back on-line fast
> enough. In fact, I would have been far more comfortable had zope been
> versioned, so that both a 2.3 and a 2.4 could exist concurrently. This
> would make site migration far easier, as the older site could be peeled
> off folder by folder and tested that way, with less fear of major
> disruption.
As I said: Zope 2.3 depends only from Python 1.5 because the *Debian*
package has this dependency. Even if I really like to see Zope 2.4.2
in Woody I see no technical reason why Zope 2.3 should not coexist
(while builded against Python 2.1).
> If we are to argue that python is "mission critical" and that "mission
> critical applications" are to be built on it; then we have to behave
> that way. And one implication of this is that we have to be very
> conservative in dropping old major releases. A two year lead time
> notice seems not at all unreasonable. That is, put a prominent notice
> that the package will be withdrawn two years from now. Put in in both
> the Debian README, and in the python-doc front page.
>
> Then, if someone comes back whining that their application no longer
> works after that date, well, at least they will have been put firmly
> on notice of the deadline, with enough lead time to do something
> about it.
This is fair.
Kind regards
Andreas.
Matthias Klose
> On 10 Dec 2001, Matthias Klose typed:
> ] Anthony Towns writes:
> ] > Dropping python1.5 doesn't seem a particularly clever thing to do.
> ] If we don't have any python1.5 dependencies, why not?
>
> Because users will have no way of having both 1.5 and 2.1 on the same
> machine as the woody python2.1 package conflicts with the potato
> python-base (1.5) package.
good point.
> If one could upgrade from potato to woody, keeping the potato 1.5
> package, and installing the woody 2.1 packages then there would be no
> need to keep 1.5 in woody.
>
> There are plenty of users who will need to test scripts on their debian
> system which will run other systems which can't be upgraded (for many
> different reasons) to python 2.1.
>
> Suggestion: keep the python1.5 packages in woody, and remove them from
> sid once woody is released as the new stable.
sounds ok.
Matthias
Donovan Baarda
> On Mon, Dec 10, 2001 at 11:44:27PM +1000, Anthony Towns wrote:
> > On Mon, Dec 10, 2001 at 07:22:36AM +0100, Matthias Klose wrote:
> > > Anthony Towns writes:
[...]
> 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.
It's far more important to drop the non-policy compliant packages that are
still hanging around. A recent look at unstable shows;
python2-ming
python2-popy
python2-tmda
Actually... that's a lot better than I thought. Looks like people are already
onto it :-)
Looking at testing shows heaps of python2-xxx packages, and even the dreaded
python-base. How do packages disappear from testing, should I file a release
critical bug against python-base?
--
ABO: finger a...@minkirri.apana.org.au for more information.
Anthony Towns
> Looking at testing shows heaps of python2-xxx packages, and even the dreaded
> python-base. How do packages disappear from testing, should I file a release
> critical bug against python-base?
Packages disappear from testing when they've been removed from unstable, and
nothing still in testing depends on them.
At the moment this biggest problems are python modules that don't build on
all architectures because not all architectures have python2.2 available,
and thus aren't get upgraded; and a few modules having RC bugs.
I'm looking into it as time permits.
Cheers,
aj
--
Anthony Towns <a...@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
"Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
see http://azure.humbug.org.au/~aj/armadillos.txt
Matthias Klose
potato). Why do you want to keep 2.3, not 2.2? Why not 2.5? IMO If you
have a mission critical application, which is incompatible among zope
versions, then you should install your own zope. Am I wrong here?
Tille, Andreas
> I would not care to be the fellow who had a mission critical application,
> who 'upgraded', and found his site no longer working, with no way of
> backing up to a working configuration.
While I agree with you in general (I wonder if it is worth a bug
report or if you should volunteer to package zope2.3 which could
coexist with zope) I have to say that somebody who does an upgrade
of a mission critical box without testing it on a test plattform
is not worth its money.
> For example, I serve technical drawings to essentially everyone in my
> company. Loss of this would cost thousands of US dollars a day,
> particularly as we no longer have a way to duplicate oversize drawings.
> (It would also cause me much grief :-( .)
Well the money for a simple testing machine would be peenuts, wouldn't it?
> Upgrade compatiblity problems would be particularly a problem for
> 2.3 users in that when 2.4 comes from unstable to testing, no 2.3
> .deb will be available, at all. 2.1 users could always go back to
> the potato package. 2.2 users, well, I hope things went well for them.
Mission critical machines should run under stable (potato).
Kind regards
Andreas.