What should we do now?
Jérôme Marant
Hi,
The latest upgrade worked fine for me. Thanks to Gregor and
Matthias ;-)
What should python modules packagers do now?
Should we stop providing support for python2 and provide
python2.1 versions of our modules now?
Thanks.
--
Jérôme Marant <jerome...@free.fr>
<jer...@marant.org>
CV consultable à l'adresse : http://marant.org
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Jérôme Marant
> [Currently I am unable to read new incoming mails ... I'll respond
> later to other messages]
>
> Just uploaded a new python1.5 NMU which fixes three bugs I introduced.
Fine.
I would have loved to see sys.path reordered the way I proposed in the
list, however.
>
> Jérôme Marant writes:
> > What should python modules packagers do now?
> > Should we stop providing support for python2 and provide
> > python2.1 versions of our modules now?
>
> - should we ship with the 2.0 packages?
We should not support 2.0 any more, IMHO.
> - for now the safest thing would be separate 2.1 packages, which are
> built independently from 2.0. So if we decide that 2.0 should not be
> shipped with woody, then we can simply remove them.
Quoted from Gregor:
"
Python package maintainers should then change their packages to build
python1.5-* and python2.1-* packages (python2.0 if needed), and make
them depend on python1.5-base etc. That would remove the need for
versioned dependencies.
"
What is the exact policy?
Should all executable scripts begin with #!/usr/bin/env python1.5 (for 1.5)
and #!/usr/bin/env python2.1 (for 2.1)?
Gregor Hoffleit
> Matthias Klose <m...@klose.in-berlin.de> writes:
> Quoted from Gregor:
>
> "
> Python package maintainers should then change their packages to build
> python1.5-* and python2.1-* packages (python2.0 if needed), and make
> them depend on python1.5-base etc. That would remove the need for
> versioned dependencies.
> "
>
> What is the exact policy?
>
> Should all executable scripts begin with #!/usr/bin/env python1.5 (for 1.5)
> and #!/usr/bin/env python2.1 (for 2.1)?
For the sake of the consistency of the Debian system, I would say that
all scripts in Debian packages currently should not use /usr/bin/env,
but instead provide the direct path to the executable (i.e.
#!/usr/bin/python1.5 etc.).
Otherwise, you might break up all the carefully provided package
dependencies by installing a new Python version in /usr/local:
Say, you would install 2.1.2 in /usr/local. Now if /usr/local/bin would
precede /usr/bin in your path, then "#!/usr/bin/env python2.1" would
call up 2.1.2. Still, if a script would depend on something like
"python2.1-base, python2.1-imaging", it would break in this case, since
python2.1-imaging isn't available in this 2.1.2 installation.
Therefore, the most reliable way currently is to use
#!/usr/bin/pythonX.Y in all Debian-provided scripts.
Gregor
Anthony Towns
> Say, you would install 2.1.2 in /usr/local.
How about we just say "Don't install other versions of python in
/usr/local" ?
Or even "If you install versions of python in /usr/local, things could
break. We don't support this."
Or even "If you install a different subrelease of the version of python
you've got installed, you'll need to be careful to install all the
modules you use for that version of python too."
Optimise for the common case, and make it easy for people to stay within
the bounds of things we support. Don't obsess about making sure an admin
can never possibly break anything.
Without the admin going out of his way to break the system (by partially
installing a version of python in /usr/local, eg) are there any real
problems with executable scripts invoking "#!/usr/bin/env python",
and having "the appropriate" dependencies?
And again, this isn't an exercise in formal specification, it's more
important to get something that's effective, useful and easily implemented
right now than something that's provably correct assuming FHS and policy.
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
Gregor Hoffleit
> Anthony Towns wrote:
> > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > > Say, you would install 2.1.2 in /usr/local.
> >
> > How about we just say "Don't install other versions of python in
> > /usr/local" ?
>
> magic is "#!/usr/bin/env python" then we would have to say "don't
> install other versions of python in your path".
Exactly. IMHO this is a no-go, we should not restrict our users in that
way. Furthermore, would there be any reason at all for using
"#!/usr/bin/env" in Debian scripts ? I don't see any.
Btw, cf. the discussion thread on python-dev that I started by asking
that kind of question. The tendency was that in general every Python
application is guaranteed to work only on a specific Python version.
Mailman 2.0 only runs on Python 1.5.2. Mailman 2.1 runs on Python 2.0.
Zope 2.2 runs on Python 1.5.2. Zope 2.4 runs on Python 2.1. Every other
combination is just a lucky coincidency (cf. the python-dev archives at
http://mail.python.org/pipermail/python-dev/ for the full discussion).
I don't see any reason why we should actively work towards enabling a
user to override the intended version, with the potential damage of
breaking scripts.
If the maintainer of a script is really aware of a legitimate reason for
doing this, he is welcome to use /usr/bin/env.
Gregor
dman
| Anthony Towns wrote:
| > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
| > > Say, you would install 2.1.2 in /usr/local.
| >
| > How about we just say "Don't install other versions of python in
| > /usr/local" ?
|
| Please no. Making this work properly is not hard. Besides, if the
| magic is "#!/usr/bin/env python" then we would have to say "don't
| install other versions of python in your path".
Actually it is simpler than that :
Don't install other versions of python in your path *with the same
name as the packaged version*.
If a script does
#!/usr/bin/env python2.1
and I install 2.1.2 as 'py212' in /usr/local there will be no clash.
Whether or not it is a good idea, I will leave up to you to decide.
-D
Anthony Towns
> Anthony Towns wrote:
> > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > > Say, you would install 2.1.2 in /usr/local.
> > How about we just say "Don't install other versions of python in
> > /usr/local" ?
> Please no. Making this work properly is not hard.
Again, _why_ does this matter? Who does this? Is it even remotely common?
That people would even consider installing another version of python in
/usr/local surely just points to a problem with the Debian packaging, no?
The problems with using "#!/usr/bin/python1.5" is threefold: first, it
makes dependencies that much more complicated: *all* python scripts have
to depend on versioned modules in every way, ie "Depends: python1.5-base,
python1.5-glade, python1.5-gtk, python1.5-numeric", second it means *all*
python executables need to be modified at the source level for every
python upgrade, and finally it makes Debian veer away from upstream
standards for python scripts.
And all this for what, precisely?
If you install new versions of standard tools in /usr/local you have
to be careful. This applies to a hypothetical /usr/local/bin/dpkg, or
a /usr/local/bin/sed, or whatever. Going out of your way to make sure
it doesn't apply to a /usr/local/bin/python seems to this observer a
complete waste of time.
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
David M. Cooke
> On Mon, Oct 22, 2001 at 08:32:33AM -0700, Neil Schemenauer wrote:
> > Anthony Towns wrote:
> > > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > > > Say, you would install 2.1.2 in /usr/local.
> > > How about we just say "Don't install other versions of python in
> > > /usr/local" ?
> > Please no. Making this work properly is not hard.
>
> Again, _why_ does this matter? Who does this? Is it even remotely common?
> That people would even consider installing another version of python in
> /usr/local surely just points to a problem with the Debian packaging, no?
>
Well, I do it for one. My reasons are two-fold: I like experimenting
with the latest, greatest, bleeding-edge python, and I also want to
compile it with optimizations (which can give me a small speedup;
important for the numerical work I do).
And not just into /usr/local: On some machines I don't have root
access, so I put it into my home directory under ~/usr. (Ok, so those
machines aren't Debian, but I think the same principle applies.)
> The problems with using "#!/usr/bin/python1.5" is threefold: first, it
> makes dependencies that much more complicated: *all* python scripts have
> to depend on versioned modules in every way, ie "Depends: python1.5-base,
> python1.5-glade, python1.5-gtk, python1.5-numeric", second it means *all*
> python executables need to be modified at the source level for every
> python upgrade, and finally it makes Debian veer away from upstream
> standards for python scripts.
Looking at my /usr/bin, I see (with the command
file /usr/bin/* | grep script | sed 's/:.*$//' | awk '{ getline a <
$1; if (a ~ /^#\!/) { print a } close($1) }' | sort
) that almost all script files specify the location of the interpreter
-- the only exceptions being some python scripts and one perl script
(all of the other perl scripts do some variant of #!/usr/bin/perl).
So, I don't think it's too much to ask that scripts that Debian
installs specify the location of the interpreter.
As for the versioned depends, how else do you want to do it? Say I
have a package python2.1-foo, which only supports Python 2.1 (it uses
list comprehensions, say). Now, assume it depends on python-gtk and
python-numeric. It has to depend on *2.1* versions of those packages,
not 1.5. This has nothing to do with the scripts in python2.1-foo
having to use #!/usr/bin/python2.1. (I use 2.1 here instead of 1.5 as
I believe there is little to prevent one from making a 1.5 package use
2.1 -- however, going to 2.2 would be more difficult).
Updating the #! line in the script would be small potatoes compared to
checking that the package works correctly with a new version of
Python.
> And all this for what, precisely?
>
> If you install new versions of standard tools in /usr/local you have
> to be careful. This applies to a hypothetical /usr/local/bin/dpkg, or
> a /usr/local/bin/sed, or whatever. Going out of your way to make sure
> it doesn't apply to a /usr/local/bin/python seems to this observer a
> complete waste of time.
[Your two examples are essential base programs in Debian -- it would
be stupid to fiddle with them, unless you know what you're doing]
I see it as: this package I installed worked, and I don't care whether
it's written in python or perl or tcl... Now, I've compiled my own
python, and the package doesn't work anymore! I see no reason why
scripts shouldn't specify exactly which interpreter they expect to be
using.
--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|coo...@mcmaster.ca
Anthony Towns
> At some point, Anthony Towns <a...@azure.humbug.org.au> wrote:
> > Again, _why_ does this matter? Who does this? Is it even remotely common?
> > That people would even consider installing another version of python in
> > /usr/local surely just points to a problem with the Debian packaging, no?
> Well, I do it for one.
And is there some reason you can't call them /usr/local/python2.1-opt, say?
Or is there some reason you can't just install all the modules you otherwise
have installed?
> And not just into /usr/local: On some machines I don't have root
> access, so I put it into my home directory under ~/usr. (Ok, so those
> machines aren't Debian, but I think the same principle applies.)
It's probably even worse on other systems, where you have no chance of
expecting that scripts outside your control have a full path to python
instead of using the /usr/bin/env trick.
> Looking at my /usr/bin, I see (with the command
> file /usr/bin/* | grep script | sed 's/:.*$//' | awk '{ getline a <
> $1; if (a ~ /^#\!/) { print a } close($1) }' | sort
> ) that almost all script files specify the location of the interpreter
Sure. Most scripts do. But we're not talking about most scripts,
we're talking about python scripts, and a large number of those use
/usr/bin/env. Of the 220 python scripts on my system, 202 of them use the
/usr/bin/env trick. This includes scripts in /usr/doc/*/examples and such
[0].
> As for the versioned depends, how else do you want to do it?
See previous messages in the thread.
If you've got a script that works with all python versions out so far,
you say:
Depends: python-base, python-glade
and the dependencies will make sure that whatever version /usr/bin/python
happens to be, and the admin will make sure that whatever python is in
the PATH is similarly sensible.
> Say I
> have a package python2.1-foo, which only supports Python 2.1 (it uses
> list comprehensions, say).
Then you'll need to say:
Depends: python-base (>= 2.1), python-gtk, python-gnumeric
and you won't have to worry when python 2.2 comes out. Alternately (depending
on how exactly this gets handled), you can end up with a dependency like:
Depends: python-base (>= 1.5), python-base (<< 2.1), python-gtk,
python-gnumeric
and your package'll work fine with both python 1.5 and python 2.0,
but will need to be double checked by hand when python 2.2 comes out
to ensure it doesn't break. And if it turns out that it doesn't break,
you can just update the dependencies, and your users don't have to care
about updating all of python to get a bug fix in your package.
> Now, assume it depends on python-gtk and
> python-numeric. It has to depend on *2.1* versions of those packages,
> not 1.5.
It needs those packages installed, but care on the part of the python-gtk
and python-numeric maintainers assures that it doesn't need to list
specific dependencies.
> Updating the #! line in the script would be small potatoes compared to
> checking that the package works correctly with a new version of
> Python.
Eh?
Checking whether a script works with a new version of python seems
generally likely to be unnecessary (already done upstream) or trivial (the
backwards incompatabilities seem to usually be pretty well documented,
and limited to things that won't affect most people).
> > And all this for what, precisely?
> [Your two examples are essential base programs in Debian -- it would
> be stupid to fiddle with them, unless you know what you're doing]
*shrug* It's stupid to fiddle with anything that's part of your system
unless you know what you're doing. If you put a messed up perl in
/usr/local/bin, you'll break shell one liners that invoke "perl" without
a full path and expect it to work as perl. If you put a messed up KDE
install in /usr/local, you'll end up not being able to build some KDE
apps properly. Big deal. There's an obvious solution: don't put messed
up programs in /usr/local; or, if you must, at least call them something
completely different.
> I see it as: this package I installed worked, and I don't care whether
> it's written in python or perl or tcl... Now, I've compiled my own
> python, and the package doesn't work anymore!
And *gosh*, all I have to do to fix it is either (a) add the batteries,
or (b) mv /usr/local/bin/python /usr/local/bin/python212opt.
> I see no reason why
> scripts shouldn't specify exactly which interpreter they expect to be
> using.
Please reread the message you just replied to then.
Cheers,
aj
[0] dpkg --get-selections | grep python | sed 's/[[:space:]].*$//' |
xargs dpkg -L | sort -u | xargs echo |
while read a; do
find $a -type f -maxdepth 0 -printf "%p: " -exec head -n 1 {} \; ;
done | grep -a '^[^:]*: #!.*python'
Gregor Hoffleit
> On Tue, Oct 23, 2001 at 01:31:50AM -0400, David M. Cooke wrote:
> > At some point, Anthony Towns <a...@azure.humbug.org.au> wrote:
> > > Again, _why_ does this matter? Who does this? Is it even remotely common?
> > > That people would even consider installing another version of python in
> > > /usr/local surely just points to a problem with the Debian packaging, no?
> > Well, I do it for one.
>
> And is there some reason you can't call them /usr/local/python2.1-opt, say?
>
> Or is there some reason you can't just install all the modules you otherwise
> have installed?
Just to make the discussion a little bit more focussed: I think several
issues were mixed up in my original mail:
(1) For once, #!/usr/bin/env has it's problems. Scripts that use
"#!/usr/bin/env python" are more fragile than scripts without.
(2) Another issue is "python" vs. "python1.5". It's a separate question
whether scripts need to be strictly coupled to a specific Python
version.
Regarding (1): If you ask me how common the situation is that people
install local Python versions in /usr/local, then I will ask you how
common it is that it's reasonable that a script provided by a Debian
package will benefit from using #!/usr/bin/env ?
Regarding (2): Making the dependency explicit (by using
/usr/bin/python1.5) is just playing safe.
As far as I can see, if we hadn't the legacy of the existing packages
and installations, and if versioned dependencies would work on all
systems in all situations, we could come up with a quite clean setup:
python-base et al. could be empty packages (virtual packages wouldn't
work!), and other packages could depend on them (e.g. "Depends:
"python-base (>= 2.0), python-gtk" for a package that need at least
Python 2.0 or better. Still in this case, what could you do if Python
2.3 broke that script ?)
But we haven't an ideal situation, so we have to fight with that kind of
legacy.
But maybe it brings us to the core of the problem:
As far as I can tell our principal problem is that there's a large set
of existing packages (from slink, potato) that have wrong dependencies
(like unversioned "Depends: python-base" for packages that depend on
Python 1.5.2) that would be (erronously) satisfied if we just continued
to use python-base and so on.
One way to resolve this is to include a huge list of conflicts in
python-base et al.
Another way to resolve this is to drop these package names, perhaps in
favour of some other package names.
IMHO, in the current, messed up situation, scripts and packages that
play safe in explicitely stating a Python version have the big advantage
that they will lead to these kinds of problems with underspecified
dependencies.
It's much the same reasoning why libraries have a number in them that
will be increased for incompatible API changes. AFAICS, with the setup
you are suggesting you can never warranty that kind of robustness.
Gregor
Donovan Baarda
> On Mon, Oct 22, 2001 at 08:32:33AM -0700, Neil Schemenauer wrote:
> > Anthony Towns wrote:
> > > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > > > Say, you would install 2.1.2 in /usr/local.
> > > How about we just say "Don't install other versions of python in
> > > /usr/local" ?
> > Please no. Making this work properly is not hard.
>
> That people would even consider installing another version of python in
> /usr/local surely just points to a problem with the Debian packaging, no?
The most common reason for installing python in /usr/local is to play with
the latest and greatest bleeding edge. Typicaly you want to play without
everything else installed on you system suddenly using and relying on your
experiment. I know that you can rename the executable to something else, but
what does a basic "make install" do?
> The problems with using "#!/usr/bin/python1.5" is threefold: first, it
> makes dependencies that much more complicated: *all* python scripts have
> to depend on versioned modules in every way, ie "Depends: python1.5-base,
> python1.5-glade, python1.5-gtk, python1.5-numeric", second it means *all*
How else are you going to ensure that a script that relies on version
1.5 of python runs using that version, when you also have python2.1-base
installed, and python-base has made the default /usr/bin/python point at
/usr/bin/python2.1? If it genuinely needs python1.5 and related modules,
there is no other way to specify the dependancies either.
I think you are mistaking this as a suggestion to always refer to a
particular version of python. This is not what is being proposed... the
#!/usr/bin/pythonX.Y" is only for scripts that explicitly rely on a
particular version of Python. For version independant or "default version"
dependant scripts, "#!/usr/bin/python" is recomended.
The real debate here is "#!/usr/bin/python[X.Y]" vs "#!/usr/bin/env
python[X.Y]" (note the X.Y is optional) for Debian scripts. From hearing the
arguments for and against, I agree with Gregor; "#!/usr/bin/python[X.Y]" is
safer and should be recommended, but packagers might have legitimate reasons
for using "#!/usr/bin/env python[X.Y]".
ie, leave it up to the package mantainers, but make them aware of the pro's
and con's.
> python executables need to be modified at the source level for every
> python upgrade, and finally it makes Debian veer away from upstream
> standards for python scripts.
This is the strongest argument for /usr/bin/env...
> If you install new versions of standard tools in /usr/local you have
> to be careful. This applies to a hypothetical /usr/local/bin/dpkg, or
[...]
but remember why /usr/bin/env was made the upstream standard; it was because
Python is not a "standard tool", and hence could be located in
/usr/local/bin, ~/bin, or anywhere. The env trick meant scripts could run
without modification on any system, regardless of where Python was
installed. In a Debian package environment, we have the benefit of a
garenteed location for python, and a dependancy system to ensure it's
actualy there.
--
----------------------------------------------------------------------
ABO: finger a...@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Donovan Baarda
> * Anthony Towns <a...@azure.humbug.org.au> [011023 09:07]:
> > On Tue, Oct 23, 2001 at 01:31:50AM -0400, David M. Cooke wrote:
> > > At some point, Anthony Towns <a...@azure.humbug.org.au> wrote:
> Just to make the discussion a little bit more focussed: I think several
> issues were mixed up in my original mail:
Noticed :-)
> As far as I can see, if we hadn't the legacy of the existing packages
> and installations, and if versioned dependencies would work on all
> systems in all situations, we could come up with a quite clean setup:
> python-base et al. could be empty packages (virtual packages wouldn't
> work!), and other packages could depend on them (e.g. "Depends:
> "python-base (>= 2.0), python-gtk" for a package that need at least
> Python 2.0 or better. Still in this case, what could you do if Python
> 2.3 broke that script ?)
This is what we should be (are?) aiming for.
As you point out below, the "safe" way to avoid the "python 2.3 broke that
script" problem is to always use "Depends: pthon-base (>=2.0), python-base
(<<2.3)", and take a punt on it breaking when 2.3 comes out.
> But we haven't an ideal situation, so we have to fight with that kind of
> legacy.
>
> But maybe it brings us to the core of the problem:
>
> As far as I can tell our principal problem is that there's a large set
> of existing packages (from slink, potato) that have wrong dependencies
> (like unversioned "Depends: python-base" for packages that depend on
> Python 1.5.2) that would be (erronously) satisfied if we just continued
> to use python-base and so on.
>
> One way to resolve this is to include a huge list of conflicts in
> python-base et al.
Matthias has done this with his packages. I think this is the way to go.
Sure, we might need to maintain the conflicts for as long as we support back
to potato perhaps... but are we required to support mixed potato/woody
systems anyway? A dist-upgrade will surely upgrade the old stuff away,
provided there are new packages in woody, won't it?
> Another way to resolve this is to drop these package names, perhaps in
> favour of some other package names.
I feel this is ugly... are we going to keep inventing new names every time
we hit this kind of problem?
> IMHO, in the current, messed up situation, scripts and packages that
> play safe in explicitely stating a Python version have the big advantage
> that they will lead to these kinds of problems with underspecified
^
not?
> dependencies.
[...]
--
----------------------------------------------------------------------
ABO: finger a...@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Neil Schemenauer
> On Mon, Oct 22, 2001 at 08:32:33AM -0700, Neil Schemenauer wrote:
> > Anthony Towns wrote:
> > > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > > > Say, you would install 2.1.2 in /usr/local.
> > > How about we just say "Don't install other versions of python in
> > > /usr/local" ?
> > Please no. Making this work properly is not hard.
>
> Again, _why_ does this matter? Who does this? Is it even remotely common?
Every Python developer I know does it.
> That people would even consider installing another version of python in
> /usr/local surely just points to a problem with the Debian packaging, no?
The python in my path is on an NFS server. It includes many extensions
that are not packaged by Debian. When we upgrade we don't want to
upgrade each box individually. Also, since we are using version 2.1.1,
yes, it's also a problem with Debian packaging. The Debian release
cycle is too long to track stable Python releases.
> The problems with using "#!/usr/bin/python1.5" is threefold: first, it
> makes dependencies that much more complicated: *all* python scripts have
> to depend on versioned modules in every way
This has nothing to do with using "/usr/bin/python(X.Y)?" vs.
"/usr/bin/env python(X.Y)?". If you want to use the latest packaged
version of Python you should use "/usr/bin/python"
> If you install new versions of standard tools in /usr/local you have
> to be careful. This applies to a hypothetical /usr/local/bin/dpkg, or
> a /usr/local/bin/sed, or whatever. Going out of your way to make sure
> it doesn't apply to a /usr/local/bin/python seems to this observer a
> complete waste of time.
The effort involved is small. Use "/usr/bin/python" instead of
"/usr/bin/env python". Use "/usr/bin/pythonX.Y" instead of
"/usr/bin/env pythonX.Y".
Neil
Anthony Towns
> Just to make the discussion a little bit more focussed: I think several
> issues were mixed up in my original mail:
Sounds like a plan.
> (1) For once, #!/usr/bin/env has it's problems. Scripts that use
> "#!/usr/bin/env python" are more fragile than scripts without.
>
> (2) Another issue is "python" vs. "python1.5". It's a separate question
> whether scripts need to be strictly coupled to a specific Python
> version.
>
> Regarding (1): If you ask me how common the situation is that people
> install local Python versions in /usr/local, then I will ask you how
> common it is that it's reasonable that a script provided by a Debian
> package will benefit from using #!/usr/bin/env ?
Well, how about you answer the question instead?
It's reasonable for Debian scripts to use #!/usr/bin/env because any
harm that could be caused is both rare and easily avoidable, and because
that's what many upstream scripts use. AFAICS.
(I don't really care if you want to encourage people to not use
/usr/bin/env, though)
> Regarding (2): Making the dependency explicit (by using
> /usr/bin/python1.5) is just playing safe.
It's not merely playing safe though. It's also creating a strict
dependency that will bite you later (by making transitions to python X.Y++
require significantly more changes, by having packages break needlessly
when those changes aren't made).
> As far as I can see, if we hadn't the legacy of the existing packages
> and installations, and if versioned dependencies would work on all
> systems in all situations, we could come up with a quite clean setup:
> python-base et al. could be empty packages (virtual packages wouldn't
> work!), and other packages could depend on them (e.g. "Depends:
> "python-base (>= 2.0), python-gtk" for a package that need at least
> Python 2.0 or better. Still in this case, what could you do if Python
> 2.3 broke that script ?)
There're two possible solutions, obviously: either you assume in advance
that scripts will work with new versions of python and allow them to be
installed together, or you assume they don't and forbid them from being
installed together.
I think that's a correct statement: I can't see any other possibilities
being even logically consistent.
If you assume that scripts will work with new versions of python,
you end up with the result that occassionally your assumption will be
wrong for some scripts, and you'll have some possible partial upgrades
that'll break. This isn't a cardinal sin.
OTOH, if you assume that scripts *won't* work, you're committing
yourselves and a bunch of other people to going through whole bunches of
Python code checking that it works, and twiddling bits to note that fact.
The only question is whether the (presumable) handful of bugs every year or
two due to the former is worth the (presumable) whole lot of effort involved
in the latter.
The easiest way to handle the latter, IMO, is to add a:
Depends: python-base (<< <X>.<Y+1>)
to the package, where <X>.<Y> is the most recent version of python that
it works with.
Note that this allows you to use a package on multiple versions of python
(so if woody were to release with python 1.5 and 2.0, your package could
conceivably Depend: python-base (>= 2.0), python-base (<< 2.3), and you
won't have to make further changes when Debian packages for 2.1 or 2.2 come
out), unlike #!pythonX.Y, which is much more restrictive.
> As far as I can tell our principal problem is that there's a large set
> of existing packages (from slink, potato) that have wrong dependencies
> (like unversioned "Depends: python-base" for packages that depend on
> Python 1.5.2) that would be (erronously) satisfied if we just continued
> to use python-base and so on.
Well there's two questions; one is working out what we want, and the other
is working out how to get there.
> One way to resolve this is to include a huge list of conflicts in
> python-base et al.
> Another way to resolve this is to drop these package names, perhaps in
> favour of some other package names.
The easiest would be to say "Packages that have an unversioned dependency,
or just a >> dependency and expect version 1.5 (but not 1.6 or 2.0 or
so on) are broken", and not care.
Depending on how many packages actually expect python 1.5, this might
even be a reasonable thing to do (if you go the route of buring the future
backwards incompatabilities bridge when you come to it, this only matters
for modules, which can probably be pretty easily replaced in one shot).
Switching the package name from "python-base" to "python" would be relatively
easy too, if the dependencies aren't maintainable.
> It's much the same reasoning why libraries have a number in them that
> will be increased for incompatible API changes. AFAICS, with the setup
> you are suggesting you can never warranty that kind of robustness.
Bumping library revisions usually just requires a recompile though,
with absolutely no source changes at all. Changing #!/usr/bin/python1.5
to #!/usr/bin/python2.0, OTOH, doesn't. One can be done trivially by an
autobuilder, the other can't.
And again: the focus here (IMAO) should be on maintaining a single,
canonical version of Python in the distribution. Having older versions
and brand new beta releases around is nice, but having the main version
be simple to handle and robust seems a lot more important. (Saying "Hey,
Debian's Python is 2.1.1! But you can't install 1.5 in /usr/local without
taking some care" is way better than saying "Debian's Python is 1.5! Yeah,
we know that sucks, but hey, you can install 2.2 and 1.6 and 2.0 all at
once into /usr/local and nothing will ever break no matter how screwed
up it is!", eg)
Cheers,
aj
William Famy
___________________________
[wf:]
good morning
This is my first mail to this mailing list.
I use woody and potato. I use python for my coding. I am waiting to python-pyqt
under woody :-)
>
> > The problems with using "#!/usr/bin/python1.5" is threefold: first, it
> > makes dependencies that much more complicated: *all* python scripts have
> > to depend on versioned modules in every way
>
> This has nothing to do with using "/usr/bin/python(X.Y)?" vs.
> "/usr/bin/env python(X.Y)?". If you want to use the latest packaged
> version of Python you should use "/usr/bin/python"
______________________________
[wf:]
This problem looks like the source.list with apt-get.
if you whant to use the stable version actualy you avec 2 choices. stable or
potato
if you choose potato you are sure not to upgrade to woody when it(he) will
become stable.
if you choose potato you are sur not to upgrade.
some peaple prefere to upgrade other not to. but theire are one thing sur when
woody will become stable the simbolic lync in the ftp will change.
so why not to do the same thing with python. python package is the last one (2.2
for exemple) with name python and python2_2 . If i need python1.5: apt-get
install python1_5
now last python is python 3.0 (only for exemple the number is false ) if you
have choose the /usr/bin/python you will use python30 if /usr/bin/python(X.Y)
you will use pythonx_y.
now if we change the actual policy to have the last python in python pacquage
this may change script using python1.5 witch do not work unde thon2.2 why not
changing the header #!/usr/bin/python to #!/usr/bin/python1_5 with a script
before upgrading to the new policy?
I hope you can understand me because of my poor english.
William
>
>
> > If you install new versions of standard tools in /usr/local you have
> > to be careful. This applies to a hypothetical /usr/local/bin/dpkg, or
> > a /usr/local/bin/sed, or whatever. Going out of your way to make sure
> > it doesn't apply to a /usr/local/bin/python seems to this observer a
> > complete waste of time.
>
> The effort involved is small. Use "/usr/bin/python" instead of
> "/usr/bin/env python". Use "/usr/bin/pythonX.Y" instead of
> "/usr/bin/env pythonX.Y".
>
> Neil
>
> --
> To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
--
\\\|///
\\ - - //
( @ @ )
+-----------------------oOOo-(_)-oOOo--------------------+
|Famy William 36 avenue des barattes 74000 Annecy France|
|email:willia...@noos.fr willia...@laposte.net |
+--------------------------------Oooo--------------------+
oooO ( )
( ) ) /
\ ( (_/
\_)
Anthony Towns
> > Again, _why_ does this matter? Who does this? Is it even remotely common?
> > /usr/local surely just points to a problem with the Debian packaging, no?
> the latest and greatest bleeding edge.
In which case you probably don't really care if you have to type "python2.2"
at the prompt instead of just "python".
> I know that you can rename the executable to something else, but
> what does a basic "make install" do?
"make altinstall" looks like it would do the right thing, unless you're
being really obsessive in which case you might need "make altinstall
VERSION=211opt" or something similarly whacky.
> > The problems with using "#!/usr/bin/python1.5" is threefold: first, it
> > makes dependencies that much more complicated: *all* python scripts have
> > to depend on versioned modules in every way, ie "Depends: python1.5-base,
> > python1.5-glade, python1.5-gtk, python1.5-numeric", second it means *all*
> How else are you going to ensure that a script that relies on version
> 1.5 of python runs using that version, when you also have python2.1-base
> installed,
Uh, how many scripts rely on python 1.5? If Debian's main python is 2.1,
why should a python 1.5 script remain available? I can't see any reason
for this, and I can't see any reason why it would even happen.
The obvious answer, anyway, is that you simply don't get to install
python 2.1 as /usr/bin/python while you have that script on your system,
due to its dependency on "python-base << 2.1".
> ie, leave it up to the package mantainers, but make them aware of the pro's
> and con's.
Which afaics concludes it as:
Use /usr/bin/python or /usr/bin/env python generally, with
dependencies of the form "python-base (>= <X>.<Y>), python-base
(<< <Z>.<W+1>)" where X.Y is the earliest version of python that's
okay (can be omitted for X.Y = 1.5), and Z.W is the latest version
known to work. (Not having the Z.W+1 dep could be cause for a
wishlist bug if Z.W+1 hasn't been released even in alpha/beta
from upstream; a normal bug if it's been released upstream,
and a serious bug if it's been released in Debian, perhaps)
Use /usr/bin/pythonX.Y with a dependency on "pythonX.Y-base"
if you wish to use a particular version of the interpretor
independent of whichever version may be default. Useful only
for legacy apps that can't be upgraded to the current version,
and apps that depend on features in unreleased versions of python.
To step back a bit, the idea is that for any Debian release we should
have a single main version of python. For woody, that'll probably be,
well, let's assume 2.0, and that for the next release it'll probably be
2.1 or 2.2. And so on. All packages that use python will be expected to
use whichever version that is. Most people (including myself) shouldn't
have to give a damn beyond this.
Now, for the wild and whacky python freaks out there this won't be enough.
Some of y'all will want to keep 1.5 around for the kludgy old app you
use that uses a couple of undocumented tricks and that no one understands
enough to port to 2.0. Others will want to use some 2.1 packages you've
snarfed off a website, but only for your own scripts because you couldn't
be bothered keeping all the other random modules in sync too. Others
will want to beta test 2.2 by doing a CVS checkout and building it
in /usr/local.
Does that sound accurate? Is there a use-case that's interestingly
different to the above?
What I'm trying to say is that the important case to consider, the one
to make as easy and efficient, and effective and reliable as possible is
the first one, not the second. Admins who need an old version of python
can cope with changing the top line in the few scripts where it matters
from /usr/bin/env python to /usr/bin/pythonX.Y. Python hackers trying
to keep up with the van Rossums ought to be able to manage to use the
"altinstall" target without breaking a sweat.
Making sweeping policy requiring lots of scripts to be modified, either
from how they are in the archive now, or on a regular basis, to avoid
the above, seems silly to me.
Gregor Hoffleit
> On Tue, Oct 23, 2001 at 02:42:42PM +0200, Gregor Hoffleit wrote:
> > Just to make the discussion a little bit more focussed: I think several
> > issues were mixed up in my original mail:
>
> Sounds like a plan.
>
> > (1) For once, #!/usr/bin/env has it's problems. Scripts that use
> > "#!/usr/bin/env python" are more fragile than scripts without.
> >
> > (2) Another issue is "python" vs. "python1.5". It's a separate question
> > whether scripts need to be strictly coupled to a specific Python
> > version.
> >
> > Regarding (1): If you ask me how common the situation is that people
> > install local Python versions in /usr/local, then I will ask you how
> > common it is that it's reasonable that a script provided by a Debian
> > package will benefit from using #!/usr/bin/env ?
>
> Well, how about you answer the question instead?
>
> It's reasonable for Debian scripts to use #!/usr/bin/env because any
> harm that could be caused is both rare and easily avoidable, and because
> that's what many upstream scripts use. AFAICS.
Certainly that's not a fair statistic, but if I grep through my
/usr/bin, there are 12 scripts using some kind of "#!/usr/bin/env
python", but 79 scripts using something like "#!/usr/bin/python" (in
/usr/local/bin, the ratio is 2 for /usr/bin/env and 4 for
/usr/bin/python).
That's consistent with my observations: The common idiom in the Python
community is "#!/usr/local/bin/python", /usr/bin/env is only rarely used.
That means most Python scripts have to be modified anyway. It's just the
question whether we should replace #!/usr/local/bin/python with
"#!/usr/bin/env python" or with "#!/usr/bin/python".
Just to make sure we have the same thing in mind: At this point,
python-base is no virtual package provided by some real pythonX.Y-base
package, but it's a real package, right ?
This would work indeed, provided a single, canonical Python version was
an option (see below).
> > As far as I can tell our principal problem is that there's a large set
> > of existing packages (from slink, potato) that have wrong dependencies
> > (like unversioned "Depends: python-base" for packages that depend on
> > Python 1.5.2) that would be (erronously) satisfied if we just continued
> > to use python-base and so on.
>
> Well there's two questions; one is working out what we want, and the other
> is working out how to get there.
>
> > One way to resolve this is to include a huge list of conflicts in
> > python-base et al.
> > Another way to resolve this is to drop these package names, perhaps in
> > favour of some other package names.
>
> The easiest would be to say "Packages that have an unversioned dependency,
> or just a >> dependency and expect version 1.5 (but not 1.6 or 2.0 or
> so on) are broken", and not care.
>
> Depending on how many packages actually expect python 1.5, this might
> even be a reasonable thing to do (if you go the route of buring the future
> backwards incompatabilities bridge when you come to it, this only matters
> for modules, which can probably be pretty easily replaced in one shot).
> Switching the package name from "python-base" to "python" would be relatively
> easy too, if the dependencies aren't maintainable.
That's a solution that came up to me yesterday night, laying in bed ;-).
Earlier, python-base was just a minimal set of Python. During the last
two years, we have merged in many things so that by now, python-base is
essentially everything from Python that doesn't depend on some exotic
stuff (like Tk, expat). Therefore, I think it would now be fair to call
this package "python".
This is something we should really consider.
> > It's much the same reasoning why libraries have a number in them that
> > will be increased for incompatible API changes. AFAICS, with the setup
> > you are suggesting you can never warranty that kind of robustness.
>
> Bumping library revisions usually just requires a recompile though,
> with absolutely no source changes at all. Changing #!/usr/bin/python1.5
> to #!/usr/bin/python2.0, OTOH, doesn't. One can be done trivially by an
> autobuilder, the other can't.
That's a valid point.
> And again: the focus here (IMAO) should be on maintaining a single,
> canonical version of Python in the distribution. Having older versions
> and brand new beta releases around is nice, but having the main version
> be simple to handle and robust seems a lot more important. (Saying "Hey,
> Debian's Python is 2.1.1! But you can't install 1.5 in /usr/local without
> taking some care" is way better than saying "Debian's Python is 1.5! Yeah,
> we know that sucks, but hey, you can install 2.2 and 1.6 and 2.0 all at
> once into /usr/local and nothing will ever break no matter how screwed
> up it is!", eg)
Sorry, but maintaining a single canonical version of Python in the
distribution won't work. That's not my opinion, that's what the Python
developers crew at python-dev told me.
Until recently, Mailman didn't work with Python >> 1.5.2. Zope 2.2
didn't work with Python >> 1.5.2. Zope 2.4 doesn't work with Python <<
2.1.
There's a very big chance that at the release date we don't have all
those applications in sync wrt. the necessary Python version. We have
then the alternative to either stick with an old Python version until
*all* Python packages are compatible with the new version, or we *have*
to support multiple Python versions in a single distribution.
Again, I wouldn't support this scheme if the Python cabal hadn't told me
that it's necessary from their point of view:
To quote just a few:
* Fred L. Drake, Jr. <fdr...@acm.org> [010703 16:04]:
>
> Gregor Hoffleit writes:
> > Seriously, does anybody (besides the Python developers) feel a need to
> > have multiple Python versions on the same system ?
>
> Absolutely! Anyone that wants to write cross-version Python code
> needs to be able to have multiple versions available. I'd even like
> to be able to have both Python 2.0 and Python 2.0.1 available on the
> same $prefix/$exec_prefix -- that can't be done currently. This kind
> of thing is pretty important when you want to take cross-version
> compatibility seriously.
>
> Barry A. Warsaw writes:
> > Yes, definitely as both a Zope and Mailman developer <wink> I need
> > multiple Python versions. But I suspect even normal users of the
> > system will need multiple versions. Different Python-based apps are
> > requiring their users to upgrade Python on their own schedule, so
> > multiple versions will still be required.
>
> Another excellent reason to support multiple versions! As more
> widely distributed applications are written using Python and don't
> want to include the interpreter, this becomes a more noticable issue.
* Guido van Rossum <gu...@digicool.com> [010703 16:36]:
> > > What about when you want to have multiple python versions, like
> > > python 1.5.2, 2.0.1, 2.1.1 and 2.2-CVS-snapshot ? :-)
> >
> > You've hit the forbidden question ;-)
> >
> > Seriously, does anybody (besides the Python developers) feel a need
> > to have multiple Python versions on the same system ?
>
> I've had enough requests over the years for this, so it is indeed
> supported, and I believe there is a need. Quite often people have
> important programs that for some minor reason don't work on a newer
> version yet and they can't find the person or the time to fix it.
>
> Python's standard installation makes this possible. You can have only
> one "python" but you can request a specific version by appending the
> "major dot minor" part of the version number, e.g. python1.5,
> python2.0, python2.1, python2.2. "python" is a hard link to one of
> these. You can't (easily) have multiple version with the same
> major.minor, but that should never be needed. I've heard though that
> some Linux distributors break this versioning scheme in favor of their
> own.
>
> > If there's a real world need for this, then, yes, we had to come up
> > with a completely different setup. I guess this setup might involve
> > symlink farms (urghh).
>
> Ugh maybe, but it's the only thing that scales.
So specifically developers of Python scripts have a legitimate need for
multiple concurrent Python versions.
And, even for the simple deployment of Python applications, it seems to
be a common understanding that it's not possible to find a singular
common version at any place in time.
A whole lot of points depend on the question whether providing a single,
canonical Python version is possible and viable for the distribution.
If it's possible, all other issues have a straightforward solution.
If that's not viable, we have to use a completely different scheme.
Do we agree about this ?
Gregor
Donovan Baarda
> On Tue, Oct 23, 2001 at 10:59:45PM +1000, Donovan Baarda wrote:
> Uh, how many scripts rely on python 1.5? If Debian's main python is 2.1,
> why should a python 1.5 script remain available? I can't see any reason
> for this, and I can't see any reason why it would even happen.
Perhaps you should read back through the archives at this point... this has
all been discussed already... and dare I say we already have a solution...
> The obvious answer, anyway, is that you simply don't get to install
> python 2.1 as /usr/bin/python while you have that script on your system,
> due to its dependency on "python-base << 2.1".
[...]
There are many _big_ applications which are tied to particular versions of
Python and upgrade at different rates to Python. Zope, mailman, etc. These
big apps would either end up including their own Python, holding back the
Debian Python, or would just not exist as debs under a "single Python"
scheme.
One of the main objectives of the slowly gelling policy has been to support
multiple versions of Python installed at once, while still allowing
applications that are not tied to a particular version to use more a general
"Depends: python-base (>=1.5), python-base (<<2.2)" and "#!/usr/bin/python"
(or "#!/usr/bin/env python") without tying themselves up.
> To step back a bit, the idea is that for any Debian release we should
> have a single main version of python. For woody, that'll probably be,
> well, let's assume 2.0, and that for the next release it'll probably be
> 2.1 or 2.2. And so on. All packages that use python will be expected to
> use whichever version that is. Most people (including myself) shouldn't
> have to give a damn beyond this.
[...]
Yep, that's the plan. We implement it with multiple pythonX.Y-base packages,
and then the python-base (X.Y-Z) package makes one of these the default by
providing a symlink /usr/bin/python to /usr/bin/pythonX.Y.
> What I'm trying to say is that the important case to consider, the one
> to make as easy and efficient, and effective and reliable as possible is
> the first one, not the second. Admins who need an old version of python
> can cope with changing the top line in the few scripts where it matters
> from /usr/bin/env python to /usr/bin/pythonX.Y. Python hackers trying
> to keep up with the van Rossums ought to be able to manage to use the
> "altinstall" target without breaking a sweat.
There is more to this than just "#!/usr/bin/pythonX.Y". Where do packages
install their python modules? Do they use /usr/lib/python2.1 because 2.1 is
the default? What happens when 2.2 becomes the default?
Read the archives for a solution :-)
--
----------------------------------------------------------------------
ABO: finger a...@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Anthony Towns
> > > Regarding (1): If you ask me how common the situation is that people
> > > install local Python versions in /usr/local, then I will ask you how
> > > common it is that it's reasonable that a script provided by a Debian
> > > package will benefit from using #!/usr/bin/env ?
> > Well, how about you answer the question instead?
Uh, I meant the question I asked. :) But anyway...
> Just to make sure we have the same thing in mind: At this point,
> python-base is no virtual package provided by some real pythonX.Y-base
> package, but it's a real package, right ?
Right.
This could be done as either:
python-base 1.5.1 Depends: python1.5-base 1.5.1 (a dummy package
just containing some docs and the /usr/bin/python link)
or
python-base 1.5.1 Provides: python1.5-base
depending on how you wanted to maintain it. (The former would make it easy
to keep 1.5 packages around when you move to 2.x, the latter would have less
dummy packages).
> This would work indeed, provided a single, canonical Python version was
> an option (see below).
I don't think it's reasonable to have anything but a single canonical
Python version; although clearly I was too dismissive of having extra
versions handy.
> Sorry, but maintaining a single canonical version of Python in the
> distribution won't work.
All this means is that on all woody systems, /usr/bin/python is the same
version of python, and that any packages that don't use that version
need a damn good reason for it.
> That's not my opinion, that's what the Python
> developers crew at python-dev told me.
> Until recently, Mailman didn't work with Python >> 1.5.2. Zope 2.2
> didn't work with Python >> 1.5.2. Zope 2.4 doesn't work with Python <<
> 2.1.
How did mailman and zope manage to end up like this? From the python.org
pages, the only backwards incompatibilities were a couple of things
about changes in arguments, that seem trivially fixable?
In any event, I *think* we're in violent agreement here: there ought
to be old versions in the archive that you can declare a dependency
on, get other modules for, and set as your interpretor; but there also
ought to be a single /usr/bin/python in any release that's used by every
"normal" package.
So if you go "apt-get install python" you end up with python 2.0 (say),
and if you follow that up by "apt-get install zope", you still have
python 2.0 for everything normal, but you also get python 1.5 (and any
necessary python 1.5 modules) in some out of the way place for zope's use.
Which would be something like:
python 2.0.1-1
Depends: python2.0
python2.0 2.0.1-1
python-apt
Provides: python2.0-apt
Depends: python (>= 2.0), python (<< 2.1)
dak
Depends: python, python-apt, apt-utils
Description: Debian archive maintainance scripts
python1.5
python1.5-ldap
Depends: python1.5
zope
Depends: python1.5
zope-ldap
Depends: zope, python1.5-ldap
The scripts in dak could then use
#!/usr/bin/env python
(which happens to be what it uses now) and rely on the modules they
import being installed and versioned correctly, meanwhile zope can use
#!/usr/bin/python1.5
and similarly work okay. If python 2.1 gets packaged, the modules all need
to be rebuilt and repackaged, but dak.deb will just keep working quite
happily. If python 2.2 comes out and breaks dak, well that's its fault,
and it could've been avoided if the dak maintainer cared by having a
"python (<< 2.1)" dependency, which would've needed to have been updated
when 2.1 came out.
You could also have, say:
python-ldap
Depends: python (>= 2.0), python (<< 2.0), python2.0-ldap
python2.0-ldap
Depends: python2.0
if you wanted to maintain python-ldap in a way that makes it easier to
keep older versions in the archive (as compared to python-apt, which
would need to be repackaged more carefully).
That's how I thought Matthias' last proposal would work anyway (well,
with python-base not python anyway).
Matthias Klose
> Sure. Most scripts do. But we're not talking about most scripts,
> we're talking about python scripts, and a large number of those use
> /usr/bin/env. Of the 220 python scripts on my system, 202 of them use the
> /usr/bin/env trick. This includes scripts in /usr/doc/*/examples and such
> [0].
If I interpret your script correctly (?), then you count all the
scripts derived from the python1.5 and 2.1 source packages, which are
modified to use the /usr/bin/env approach. That leads to wrong
numbers.
Matthias Klose
> On Tue, Oct 23, 2001 at 06:13:31PM +0200, Gregor Hoffleit wrote:
> > > > Regarding (1): If you ask me how common the situation is that people
> > > > install local Python versions in /usr/local, then I will ask you how
> > > > common it is that it's reasonable that a script provided by a Debian
> > > > package will benefit from using #!/usr/bin/env ?
> > > Well, how about you answer the question instead?
> > Certainly that's not a fair statistic,
>
> Uh, I meant the question I asked. :) But anyway...
>
> > Just to make sure we have the same thing in mind: At this point,
> > python-base is no virtual package provided by some real pythonX.Y-base
> > package, but it's a real package, right ?
>
> Right.
>
> This could be done as either:
>
> python-base 1.5.1 Depends: python1.5-base 1.5.1 (a dummy package
> just containing some docs and the /usr/bin/python link)
>
> or
>
> python-base 1.5.1 Provides: python1.5-base
>
> depending on how you wanted to maintain it. (The former would make it easy
> to keep 1.5 packages around when you move to 2.x, the latter would have less
> dummy packages).
I would prefer the former. It provides a basic python for packages
that cannot be upgraded.
> > Sorry, but maintaining a single canonical version of Python in the
> > distribution won't work.
>
> All this means is that on all woody systems, /usr/bin/python is the same
> version of python, and that any packages that don't use that version
> need a damn good reason for it.
I agree on this interpretation of canonical version.
> > That's not my opinion, that's what the Python
> > developers crew at python-dev told me.
> > Until recently, Mailman didn't work with Python >> 1.5.2. Zope 2.2
> > didn't work with Python >> 1.5.2. Zope 2.4 doesn't work with Python <<
> > 2.1.
>
> How did mailman and zope manage to end up like this? From the python.org
> pages, the only backwards incompatibilities were a couple of things
> about changes in arguments, that seem trivially fixable?
I really don't care why they ended there. It's legitimate for a package
maintainer not to diverge from the upstream version and stay with an
old version.
> In any event, I *think* we're in violent agreement here: there ought
> to be old versions in the archive that you can declare a dependency
> on, get other modules for, and set as your interpretor; but there also
> ought to be a single /usr/bin/python in any release that's used by every
> "normal" package.
we agree. (and there could be newer versions, which cannot be made the
"normal" version soon enough).
> So if you go "apt-get install python" you end up with python 2.0 (say),
say 2.1 and we agree.
> and if you follow that up by "apt-get install zope", you still have
> python 2.0 for everything normal, but you also get python 1.5 (and any
> necessary python 1.5 modules) in some out of the way place for zope's use.
>
> Which would be something like:
[well explaining example removed]
> That's how I thought Matthias' last proposal would work anyway (well,
> with python-base not python anyway).
So you did understand me correctly, perhaps you could reword the
policy proposal, where I am unclear (hint, hint, ... ;-) And even the
python-base -> python substitution sounds ok, now that we know that
100 conflicts on a line are a bad idea.
Matthias
Btw, where can I find python-apt ;-)
Carey Evans
[...]
> Gregor pointed out that python-base is almost a complete python
> package, so we could rename it and "reuse" the name "python",
> "python1.5", "python2.1" for the base packages.
As far as I'm concerned, this is identical to my idea, just with a
much better name for the package, so I'm all for it.
> Package: python
> Depends: python2.1
> Conflicts: python-base, <plus the 10 other packages, which depend on
> python, but do not declare a versioned dependency>
If we were willing to accept some breakage in testing and unstable,
then it looks like only bg5ps, grmonitor, pythondoc and sketch would
need to be included in this list, making it even simpler. It's even
possible some of them still work with Python 2.1.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Ha ha! Puny receptacle!"