Re: The Python Registrar
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 abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: