Quoting Matthias Klose <[EMAIL PROTECTED]>: > 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 [EMAIL PROTECTED] for more information.