Re: (another set of) experimental packages (1.5, 2.1, 2.2a4)
Donovan Baarda writes:
> Some other questions;
>
> what happens with other packages that might/might not have installed
> stuff into /usr/lib/python1.5? Will they break?
No. However the priority of the python alternative from 1.5 should
greater than the prio of the pyton from 2.x (at least for some
intermediate time).
> 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?
Not yet addressed. Writing something comparable to the emacs
registration should work for all binary-indep packages:
- install these files into /usr/lib/python/site-packages (do not
include this in sys.path.
- symlink each file in /usr/lib/python/site-packages to each file
in /usr/lib/pythonX.Y/site-packages (for all X.Y).
- compile all .py files in /usr/lib/pythonX.Y/site-packages (for all
X.Y).
- installing a new python version would do this for all already
installed packages.
How safe is this schema for arch dependent packages?
> 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 don't care. Probably Gregor called it this way, because it is an
applicaton, not a library.
> 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.
so the user doesn't expect the whole python installation if he
installs python-base?
> 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.
mpz and tk are arch dependant, examples not.
> 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.
seems to be a mistake. should be idle instead of idle-python. Probably
a good idea to rename this the new packages to idle1.5 und idle2.1
> 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).
why is this necessary?
> 4) Make python-base provide a symlink /usr/bin/python to
> /usr/bin/python1.5. This would establish python1.5 as the current
> default.
could be done with alternatives.
> 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.
you would need this schema for each python-dependent package...
> 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.
python-foo would depend on python-bar and python-baz. python-bar is
available for 1.5 only, python-baz for 2.1 only. The dependencies are
fulfilled ...
> 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.
Send in you scripts ;-)
Reply to: