On Sat, Feb 23, 2002 at 03:31:26PM -0500, Jim Penny wrote: > > > > On Fri, Feb 22, 2002 at 07:03:59PM -0500, Jim Penny wrote: > > > On Sat, Feb 23, 2002 at 10:38:17AM +1100, Donovan Baarda wrote: > > > > On Tue, Feb 12, 2002 at 12:05:22AM +0100, Bastian Kleineidam wrote: > > [...] > > > > Did you see my analysis and modified "register-python-package" script? I > > > > posted it under a misleading subject by mistake (responded to another > > > > thread > > > > that migrated onto it). > > > > > > > IMHO python programs are much easier. > > OK, I will agree with that. > > > The python-central approach attempts to provide a single package that > > supports multiple versions of python. > > > > > Education of end-users and even packagers is important. It cannot be > > > overemphasized to all involved that this works only for pure python > > > modules (and maybe pure python programs). It does not, can not, and > > > probably will never work for python "C-extension" modules. > > > > Yeah, but the policy already acknoleges and supports that, and quite well. > > > > > This does worry me a bit. It requires end-users to know the difference. > > > How do we educate them? > > > > End users don't have to know the difference, provided packagers get it > > right. The dependancies will handle it all for them. > > > > Ah, but they do. Some packages install automatically, even in places > that they are not necessarily wanted ("pure python modules"). Some > never install automatically, even in places where they are wanted > ("C-extension modules"). [Although C-extension modules should be > automatically upgraded when the default python changes.] This is really > quite different behavior and requires whoever has root to know and make > the distinction.
The packages, provided they are built right, will be pretty self explanitory. Installing "python-foo" will install python-foo for the default python, "python2.1-foo" will install python-foo for python2.1. You are right that if "python-foo" happens to be a python-central package, it will also install for any other installed and supported python versions, but I can't see that this is a problem. If it is a python-central package, there will be no corresponding "python2.1-foo" package. For C module's, admins wanting to add python-foo for version 2.1 will have to explicitly install "python2.1-foo". Note that if python2.1 happens to be the default python, "python-foo" will be an empty package that depends on "python2.1-foo". Of course, the current policy does not require that packagers support all versions of python, so there is no garrentees that "python2.1-foo" will exist, or that a python-central "python-foo" will support python2.1. A quick glance at the dependancies will tell you what python-foo works for. > Restated, if you think of these packages only as "python modules", it may > violate the principle of least surprise that sometimes you install a > package and forget about it, and other times you install a package and > have to reinstall each time an additional python is introduced to the > system you administer. You don't have to re-install every time an additional python is introduced. If python-central becomes accepted as part of the policy, installing a new python will compile all python-central modules for the new python in the pythonX.Y's postinst. -- ---------------------------------------------------------------------- ABO: finger [EMAIL PROTECTED] for more info, including pgp key ----------------------------------------------------------------------