[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: (another set of) experimental packages (1.5, 2.1, 2.2a4)



G'day,

Hope you don't mind me Cc'ing to you guys. Let me know if you don't like it and 
I'll stop.

Quoting Matthias Klose <doko@cs.tu-berlin.de>:
[...]
> Open issue(s):
> 
> - didn't handle the conversion/recompilation of /usr/local python
>   packages.

Some other questions;

what happens with other packages that might/might not have installed stuff 
into /usr/lib/python1.5? Will they break? What is the plan for these packages 
to support 2.x python? How are version independant python addons going to be 
supported for all/latest versions of python?

I have only looked at the Packages.gz file so far, but which of these packages 
include /usr/bin/python, or is there only /usr/bin/pythonX.X? 

> Tested with an upgrade from an uptodate unstable system.
> 
> Please send feedback to (flight@debian.org and doko@debian.org) or to
> this list.
> 
> I didn't follow Neil's package schema, because it doesn't allow an
> incremental transition from one version to the next. Compare the
> python core libraries with something like libc5/libc6. We do have
> separate dependent packages libfoo1 and libfoo1g to avoid upgrade
> problems, so it's the the safe we to go. Another point in the
> discussion was the upgrade to another python version. Sure, the old
> package will stay (but won't hurt). New packages will be installed if
> applications using the packages are installed. Remaining problem: you
> only install the python packages for your own development, you will
> have to select the packages manually.

I notice that you have idle-pythonX.X instead of pythonX.X-idle. Any particular 
reason for that? Can we decide on a convention for this at least? I prefer 
pythonX.X-idle myself. Putting the python bit first means they naturaly cluster 
together in sorted lists. I'd prefer it for all specificly python related 
packages, but it should be compulsory for at least parts of python proper. I 
know idle is a bit border-line, but it is part of the official windows python 
bundle.

You also have pythonX.X-base provides pythonX.X instead of just a pythonX.X 
package. Is there any benefit to this? It seems like a small bit of added 
complexity for no particular reason.

Do things like python2.1-mpz and python2.1-tk really depend on python2.1-base 
(=2.1.1-0.2), or would they work with python2.1-base (>=2.1.1-0.2) like 
python2.1-examples? IMHO it is a good idea to avoid having to upgrade packages 
just to adjust the dependancies if at all possible.

There are some small changes that would make these packages be a hybrid between 
a purely versioned python and Neil's scheme. Like the following;

  1) Make the packages python-dev, python-doc, python-elisp, python-examples, 
python-gdbm, python-mpz, python-regrtest, python-tk, python-xmlbase and python-
idle more than just transition packages. Make them also function as wrapper 
packages that pull in and establish one particular version of python as the 
default.

  2) Add a package python-idle (or idle-python) similar to existing idle 
package.

  3) To python-dev, python-doc, python-examples, python-gdbm, python-mpz, 
python-regrtest, python-tk, and python-idle add Depends: python-base (=1.5.2-
17.0.2).

  4) Make python-base provide a symlink /usr/bin/python to /usr/bin/python1.5.

This would establish python1.5 as the current default. When everyone is ready 
to make python2.1 the default, new releases of the python-dev, python-doc, 
python-elisp, python-examples, python-gdbm, python-mpz, python-regrtest, python-
tk, python-xmlbase and python-idle wrapper packages can be released that all 
have "Depend: python-base (=2.1.1-1), python2.1-xxx". The new python-base would 
provide a symlink /usr/bin/python to /usr/bin/python2.1.

This allows other packages to depend on just python-base, python-gdbm, etc if 
they just want to use the default version of python. Packages that want to use 
a particular version of python can depend on pythonX.X-base, pythonX.X-gdbm, 
etc.

For true transperant support of version-independant packages we still need to 
resolve the issue of where they put their files and how they get compiled. My 
solution is to have them put their files in /usr/lib/python, and have python-
base provide a script that creates and compiles symlinks to them in 
all /usr/lib/pythonX.X directories. I guess this should probably also 
support /usr/local/ python stuff.

--
ABO: finger abo@minkirri.apana.org.au for more information.



Reply to: