Re: (another set of) experimental packages (1.5, 2.1, 2.2a4)
Quoting Matthias Klose <doko@cs.tu-berlin.de>:
> 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).
Ahh, you are using alternatives... I didn't pick that up from looking at the
packages file. (I live below the bandwidth poverty line, so downloading test
packages is out of the question, hence my fixation with avoiding unnecisary
package updates :-). My alternative description of minor package changes for a
hybridized Neil scheme wouldn't use alternatives.
The problem with alternatives is there is no way that dependancies can
definitely identify what packages must be installed for a program to work. Part
of the problem is dependancies can't specify which alternative is active. The
other part of the problem is unversioned applications depending on versioned
modules. For example;
Program spam depends on python and python-eggs. Module python-eggs is a
compiled extension module and hence comes in versioned flavors; python1.5-eggs
and python2.1-eggs. These go with python1.5 and python2.1 respectively. How can
spam specify it's dependancies to ensure it works, and how can these
dependancies be specified in a way that is "future proof" for when python3.0
comes out? spam depends on pythonX.Y and pythonX.Y-eggs where pythonX.Y is the
prefered alternative, which is a bit tricky to specify.
spam can't just depend on python and python-eggs, because this might be
provided by a combination of python1.5 and python2.1-eggs with python1.5 the
prefered alternative. A fully versioned dependancy of python1.5 and python1.5-
eggs ties it to a particular version of python, and can also break if these are
installed but python2.1 is the prefered alternative.
There is no combination of wrapper packages, virtual packages, and strange
dependancies that can specify this complicated dependancy that I can figure
out. This is the reason the Perl guys dumped it and went for a "one true Perl"
approach. Since Perl is critical to Debian, they couldn't afford to have things
like dpkg break.
Fortunately, Python is not so critical, so we can probably get away with a
little bit of breakage. Anyone with half a clue could figure out that spam was
broken using python1.5 with python2.1-eggs, even if the dependancies can't. I
still think alternatives is viable, provided we are prepared for the breakages
and extra end-user intelligence required.
> > 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:
Hmm. not familiar with this. Does emacs keep some sort of list of registered
packages? Your description below doesn't seem to require such a list.
> - 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?
Any version dependant packages will have to be handled differently to version
independant packages. The above is safe for version independant packages only.
Packages that are version dependant should install themselves directly
into /usr/lib/pythonX.Y/site-packages, and there needs to be a different
package for each different supported version of python.
> > 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.
Is this an already established defacto policy? I'm not fussed either way, but a
policy would be good :-)
> > 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?
fairy Nuf.
> > 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.
how arch dependant are they? Would python2.1-mpz (2.1.1-0.2) really break with
python2.1 (2.1.1-1.0)? Would it break with python2.1 (2.1.2-0.1)?
I thought that even binary extension modules didn't break for micro changes in
python.
> > 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
I was using my assumption that idle is part of python.
Any program or module that is dependant on a particular version of python needs
care. In the case of idle, idle1.5 should depend on python1.5-base and
use /usr/bin/python1.5, and idle2.1 should...etc. To avoid conflicts between
the two, they should either; conflict with each other, use alternatives, or use
an "idle" wrapper package to make one the default.
> > 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?
This scheme relies on a "default" version of python and "default" versions of
extension modules to all work together. This allows version independant
programs and modules to simply depend on the "default" version by specifying a
dependancy on the un-versioned wrapper packages.
To ensure that the un-versioned wrapper packages (ie python-base, python-mpz)
are all pulling in the same "Default" version of the versioned packages (ie
python1.5-base, python1.5-mpz), they are version-tied together.
ie python-mpz (1.5.2-17.0.2) will break with python-base (2.1.1-xx) because it
makes python1.5-mpz the "default" python-mpz, whereas the updated python-base
makes python2.1-base the "default" python-base.
> > 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.
Yes, it could be, at the risks outlined above. This approach removes the
flexibility of alternatives by using a "python-base" wrapper package to
make "python1.5-base" the enforced "alternative". However, this also makes it
possible for packages to specify dependancies that gaurentee they will work,
and be "future-proof" so they will work unchanged with future versions of
Python.
I have a feeling that alternative priorities _might_ be usable in a similar
way, provided no-one overrides the priorities. However, I haven't fully thought
it through, and I'm not sure it can solve the dependancies problem. Also,
adjusting alternative priorities requires releasing a whole new package, rather
than just a small wrapper package.
> > 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...
Yes. Every package that is dependant on a particular version of python would
need this schema if they wanted to work with all versions of python and wanted
to provide a "default" for other packages to depend on. However, packages that
don't depend on a particular version of python could just use "Depend: python-
base, python-xxx,..." and would not need to be updated every time python is
updated. They would just use the "default" python specified by the un-versioned
wrapper packages.
Packages that require a particular version of python don't have to follow this
schema if they don't want to work with all versions or provide a "default"
version. They can simply use "Depend: python1.5-base, python1.5-xxx,...", and
update the package with new dependancies when they've fixed it for a new
version of python. However, any packages that depend on these packages will be
tied to whatever version of python they are tied to, and must specify the
versioned packaged for any other python dependancies; ie "Depend: spam,
python1.5-base, python1.5-xxx,..." because spam has "Depend: python1.5-base"
> > 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 ...
Nope... python-bar (1.5.2-1.0) depends on python-base (=1.5.2-1.0) and
python1.5-bar. python-baz (2.1.1-1.0) depends on python-base (=2.1.1-1.0) and
python2.1-baz. These incompatible versions of python-bar and python-baz cannot
be installed together because they depend on different versions of python-base.
python-foo's dependancies cannot be met until there is a compatible pair of
python-bar and python-baz wrapper packages.
> > 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 ;-)
Got me there :-) At this stage I'm an ideas man only (AKA wanker). I might get
around to providing scripts in the future when some sort of policy starts to
gel a bit more.
--
ABO: finger abo@minkirri.apana.org.au for more information.
Reply to: