pkgsrc-Users archive

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

Re: [HEADS UP] Removing python24 and python25

Jörn Clausen <> writes:

> On Fri, Mar 2, 2012 at 12:49 AM, Greg Troxel <> wrote:
>> [non-ASCII characters that I didn't send removed from the quote]
>> package with no suffix is the latest stable, and suffixes are old
>> versions
>> seems reasonable as well. And after adding that, we have arrived, more
>> or less, at the current state, so I'm not sure what you want to change.
> That's not true for python, there is no package without a version
> number.

Agreed; I meant that we have a mix of always-suffixed packges and some
where the current version is not suffixed.

> Which is, in a way, the problem one of my users had, when I
> switch from Python 2.5 to 2.6 a few weeks ago. As all packages are
> versioned, the name of the interpreter changed from python25 to
> python26.

This is a completely separate issue from the package name.  The emacs22
and emacs packages both install emacs, and one can have one or the
other.  python, on the other hand, can be installed in parallel.  This
is necessary because python upstream has poor inter-version
compatibility, and you can't just take code that works on 2.5 and run it
on 2.6.  Because so many things depends on python, the only sane thing
to do is to have parallel-installable python versions, with
parallel-installable modules to go with.

> I don't know if his software has problems per se to change
> from 2.5 to 2.6, but at least the changed name of the interpreter
> broke his application. Having a consistent name for a binary would be
> IMHO a nice side effect of having a default package without a version
> number.

I see your point about a name without a suffix, but with python we have
to have multiple versions installed.

Once you have can have multiple versions, using programs have to find
the interpreter and see if it is acceptable, and also find if the
required modules are installed, etc.   If python were one day 2.5, and
then because 2.6, then programs using it would suddenly see a different
set of modules.

That said, people can certainly symlink python to python2.6 if that
convenience outweighs the variable binding risk.

Your user's program should probably find python via configure and
subsitute the interpreter path.   In my view, that's just how it is when
one uses a family of languages rather than a language.

> The Java packages are another example, where the name of the
> "interpreter" changes with every package. Some mechanism to say "this
> is the (or even better: 'my') default package, and it provides
> /usr/pkg/bin/python, /usr/pkg/bin/java, etc." would provide another
> aspect of stability. At least as long as the application is compatible
> with the different versions of Python/Java/etc, of course.

That's the problem.  We have arrived at the current situation precisely
because python and java are not names of languages, but families of
related languages.  python 2.5, python 2.6, openjdk X, etc. are names of

When we upgraded gcc, it was replaced, not used in parallel, and while a
lot of things needed fixing, it was because the old code was wrong, not
because the language specifications implemented by the two compilers are

Sorry if this sounds like a rant - but I think the underlying causes of
the pain your user is having are real and due to python changing the
language in incompatible ways.

Attachment: pgpAh5Fxxhgvr.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index