From owner-freebsd-ports@FreeBSD.ORG Fri Oct 1 06:59:35 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F6681065673; Fri, 1 Oct 2010 06:59:35 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 92AB08FC27; Fri, 1 Oct 2010 06:59:34 +0000 (UTC) Received: from mobileKamikaze.norad (HSI-KBW-078-042-098-160.hsi3.kabel-badenwuerttemberg.de [78.42.98.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 9908F8A27CD; Fri, 1 Oct 2010 08:59:32 +0200 (CEST) Message-ID: <4CA586D4.8090903@bsdforen.de> Date: Fri, 01 Oct 2010 08:59:32 +0200 From: Dominic Fandrey User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-GB; rv:1.9.1.12) Gecko/20100918 Thunderbird/3.0.8 MIME-Version: 1.0 To: Doug Barton References: <4CA256B6.5090908@FreeBSD.org> <4CA5176B.7080706@FreeBSD.org> In-Reply-To: <4CA5176B.7080706@FreeBSD.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: Using portmaster with different PYTHON_VERSION X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 06:59:35 -0000 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: >>> >>> 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?