[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Second report: latest python in unstable broke my packages



Quoting Bruce Sass <bsass@freenet.edmonton.ab.ca>:

> Hi,
> 
> On 16 Oct 2001, Jérôme Marant wrote:
> <...>
> >   I installed both python1.5 and python2.1. And installing both on the
> same
> >   system broke _all_ my python 1.5 packages: this is the alternative
> issue
> >   Perl people have warned us about.

I didn't think the new packages were using alternatives?

> >   I discovered that /usr/bin/python is pointing to python2.1, so
> running those
> >   python 1.5 scripts makes them fail.
[...]

looking at the current unstable Packages file, it looks like the updates to 
python2.1 are not in there yet. If they are, then they haven't been done as 
well as the python1.5 packages. I've only looked at the Packages file so far, 
so I might have missed something. The python1.5 packages look like they are 
well structured for a clean transition.

python-base (1.5.2-18.1) depends python1.5-base, provides python
python1.5-base (1.5.2-18.1) provides python1.5, replaces python-base (<=1.5.2-
17), conflicts python-base (<=1.5.2-7)

This will safely replace the old python-base, replacing it with python1.5-base. 
The new python-base presumably establishes python1.5 as the 
default /usr/bin/python. Note that the new python-base has a comment that 
suggests it is a transition package that can be removed later on. I'm not sure 
that this is correct, as it effectively provides the dependancies that other 
non-version specific python modules and applications can depend on (ie python-
base and/or python).

The python2.1 packages must not be updated yet;

python2-base, provides python2
python2.1-base provides python2.1

No conflicts/replaces etc. These two packages could be installed together, 
except that they over-write each others files.

> >   FYI, my packages are python-4suite and python-xml.
> >
> >   Was that issue expected?
> 
> Yes.
> 
> It seems to be a convention issue.

I had to laugh at this... :-)

Without an up to date Python policy, how can anybody know of the conventions, 
or even have any? Niels initial attempt had flaws, but at least it was an 
attempt. I'd like to see it updated.

Even thought the existing 1.5 packages seem OK, they raise some questions. 
Should version independant packages depend on python or python-base? The same 
with version dependant packages; python1.5 or python1.5-base? How are version 
independant modules going to be handled, or are all modules going to be tied to 
a particular version? The additions of these "provides" was IMHO redundant.

> Code depending on Python-2.x can use the virtual "python2"
> interpreter;  provided by any 2.x package, managed by alternatives
> or maybe a debconf interface and some utilities (?).  A "python1"
> should not be necessary, but a "python3" may be when the potentially
> code-breaking Python-3.0 is released.

This is neat. I take it this means there will be a wrapper package python2-base 
that selects a particular /usr/bin/python2.Y as the default /usr/bin/python2

--
ABO: finger abo@minkirri.apana.org.au for more information.



Reply to: