Using portmaster with different PYTHON_VERSION

Dominic Fandrey kamikaze at bsdforen.de
Fri Oct 1 06:59:35 UTC 2010


On 01/10/2010 01:04, Doug Barton wrote:
> On 9/29/2010 1:57 PM, Dmitry Pryanishnikov wrote:
>> Hello!
>>
>> 2010/9/28 Doug Barton<dougb at freebsd.org>:
>>>
>>> I would also argue that there is a fundamental assumption in the ports
>>> infrastructure that what you're doing here (installing both versions
>>> on the
>>> same system) is not supported. The ability to make the version of things
>>> like python or perl variable is a great feature of the ports
>>> infrastructure,
>>> but my understanding has always been that this would be a system-wide
>>> option, and that installing different versions of the same language
>>> on the
>>> same system is not supported.
>>
>>    What problems (besides no support in portmaster) can arise due to
>> parallel use of Python 2 and Python 3 in the same FreeBSD system?
> 
> I'm not an expert on python so I'll let someone more knowledgeable
> comment on that. There may not even be any problems.

I'd assume this is a correct assumption. I wouldn't expect any problems.

> My point was simply
> that historically the assumption has been that there would only be one
> version of a given interpreted language (like perl or python, and to
> some extent php, and others) on a system at a time. Your post eloquently
> stated the case for why that assumption might no longer be true. If
> that's the case, then the way we do some things might have to change.

I've been thinking whether I could abandon the assumption that there
is only one package per origin in pkg_upgrade. I decided against it,
because the change would be too fundamental. If the assumption was
scrapped, there would no longer be a unique identifier for packages
across versions and this would introduce guesswork into every layer
of code.

There is already tons of guesswork in reading the command line
parameters, there are 13 different things that can go wrong with
packages specified on the command line. Because they can go wrong
in different situations (e.g. regular reinstall request or -o), the
code currently produces 19 different kinds of error messages just
for specified package names. There are another 38 error messages for
redundant and conflicting options/flags. Imagine to introduce this
degree of error handling into every layer of a package management
tool.

As far as I am concerned the correct solution would be to create
py- slave ports for every major branch, i.e. py2-* and py3-* ports.
This way you could have one python version from every major branch,
which I'd expect to suffice for most use cases.

An alternative would be to have the py-* packages depend on
lang/python and make that depend on more than one version of python.
I.e. it should allow to select all desired python versions through
the OPTIONS framework.
The py-* ports then would have to be changed to install themselves
for all available python versions they support (this should be
possible with a little Makefile magic and dynamic plists). I expect
this approach would also work well with the build systems pointyhat
and tinderbox.

If the ports tree introduced a new unique identifier that crossed
version boundaries, was present in INDEX files, +CONTENTS files
and of course could be produced by the Makefile, it would be far
less trouble to get rid of the origin 1-1 package relation assumption.
It would be a lot of work, because the assumption is so heavily
relied on, but it would not be very difficult.

Regards,
Dominic

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? 


More information about the freebsd-ports mailing list