Re: Debian Python Policy [draft]
Jim Penny wrote:
> I just want to ask a couple of questions to make sure that I understand
> this in detail. Suppose python2.1 is installed as python and you
> also have python1.5 installed. You have
> script poo which is invoked via #!/usr/bin/python and
> script bah which is invoked via #!/usr/bin/python1.5
>
> > 1.2. Module Path
> > ----------------
> >
> > Python searches a number of directories for modules. The module
> > search path for Debian has been ordered to include these locations at
> > the beginning of the path in the following order:
> >
> > /usr/local/lib/site-python
> > /usr/local/lib/python<X>.<Y>/site-packages
> > /usr/lib/python<X>.<Y>/site-packages
>
> The debian search path for poo is (possibly in some other order, per
> later messages):
>
> /usr/local/lib/site-python
> /usr/local/lib/python2.1/site-packages
> /usr/lib/python2.1/site-packages
> ...
>
> and the debian search path for bah is:
>
> /usr/local/lib/site-python
> /usr/local/lib/python1.5/site-packages
> /usr/lib/python1.5/site-packages
> ...
>
> ?
>
> (that is, even in the 'python' package, versioned paths are used.)
That's right.
> > 4.1. Building Embedded Programs
> > -------------------------------
> >
> > Programs which embed a Python interpreter must declare a
> > `Build-Depends' on `python-dev'.
> >
>
> Versioning? If a package requires the dev for python1.5, will we
> be providing a python1.5-dev?
Yes, I'll add that to the document. In general though packages should
try to use the latest version of Python. Versioned packages (as in the
version in the name) cause lots of pain and we should try to keep them
to a minimum.
> Finally, what about package naming. Suppose I were maintaining
> python-popyda (which I happen to be). Suppose python (2.1) is released
> and it turns out that python-popyda is incompatible with it (I am not
> saying it is, I just want a concrete hypothetical). Should
> python-popyda be renamed to python1.5-popyda as soon as possible?
I don't think so. If there is only one popyda package then it should be
called "python-popyda". It should depend on python-X.Y. Hopefully X.Y
is the latest stable Python release.
> Or should it remain as python-popy with a conflicts that prevents
> it from being used with python (2.1)?
Conflicts should not be necessary.
> Suppose a later version comes out which is 2.1 available, but for
> some transition period, I want to provide both a 1.5 and a 2.1
> compatible version. Should package names be python1.5-popyda and
> python-popyda?
In that case you should provide a python-1.5-popyda package. I'm hoping
we can avoid doing that for most packages but the mechanism is there if
we need it.
> Again, I have some reservations about breakage on a mass scale
> when a new major of python comes out with this scheme, but I guess
> paranoid maintainers can take care of that by routinely making an
> equality depends in our packages.
The breakage should only happen once or twice in the Debian development
cycle (i.e. when a new version of Python gets uploaded). Since
extension modules depend on the major and minor version of Python that
they are compiled against I see no way of eliminating the problem. When
a new version of Python gets uploaded, a legacy version should probably
get uploaded as well. For example, if the current "python" is 2.0 and
the new "python" is 2.1 then "python-2.0" could be provided to ease the
transition. The "python-2.0" package could be removed if there was no
"python" version 2.0 in an official Debian release.
Neil
Reply to: