From owner-svn-ports-all@freebsd.org Mon Oct 9 03:02:49 2017 Return-Path: Delivered-To: svn-ports-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F21C9E46476; Mon, 9 Oct 2017 03:02:48 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D1B77C12F; Mon, 9 Oct 2017 03:02:48 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pf0-x230.google.com with SMTP id m28so7471199pfi.11; Sun, 08 Oct 2017 20:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:reply-to:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=96VeMYE6VdhVuXpP6h+lqDJKeM5B9wTuSHJ8K4skMMA=; b=NTr5n/Zv8kbUOnM9R+oZUxb7e/+HjqhQfEgYSudl9z6shXEdx8On9uBzoJQgbGP4Qb Z6o/1iltIfV/5Z8NIp4YyL5iSd6SOaf2tNDxaR4wuUpOOwaAZaL35PulNofnAp3nZ0x8 S4t8DRHdXFAb9NIHCJ7s+ZxhOujubzwiIesEfQN3q0PDgOPVIpE7j7qbCAxGGSJwHl+t /jAPnQU7gKkmA3FGTdHMwq+0BvgJdXr0bLSSDMAZ9WrmtSv5HyezqpsrMuE5nIT6J1oG Au4Xg7VBJXhhv5grRLS4wVp5sWJyevQyb3p17bYM7Faa9eI++RFnb7SRHc9RH/x04U6X seqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=96VeMYE6VdhVuXpP6h+lqDJKeM5B9wTuSHJ8K4skMMA=; b=AdOUoR272sQE3tPGLD3uB7SpjP/SqnVYtbjNJNHRYilvATknHA4iO4D12M86sDXPnk Mq2GRdBhUuCyPx5/gka5PUhhyPw1XbqikXI9MYen7C4n5NCACkM7I/eIhaSROUWZ5yly dJ1kKl4LUbq4QYd1XtAZyvYMkt1h+enmP/t+HDj3UL2MZOylPd6mENiXh2yw43HRM381 uQqCQCFi78Bd9iaVp3T3ar4anmdcViozS+qLKc6xEu3FjEusMQtC2FrwMBiRQcHsYtEA /dzYk/SqJ+28kWz/s4981yWasuPL2i4PT0EGNDDBmVcEbifQKR3kaw3BflkPBW9zfczH Nk0g== X-Gm-Message-State: AMCzsaUp22/O4jPMWXHDu/zcG6BdwXwAHke5c6oZGdVDo5JsMw9x9U3W tCru/SPa9YAX1wedSZ3SZv5gjCDJ X-Google-Smtp-Source: AOwi7QBu8HdpMzgPb0vJFZq9xNQ4Ul2S7Jr/vPYYOC2ILOy4EaTgSOi041nPGqTpFdWn7IE5o3ufXQ== X-Received: by 10.84.233.66 with SMTP id k2mr732533plt.45.1507518167689; Sun, 08 Oct 2017 20:02:47 -0700 (PDT) Received: from ?IPv6:2001:44b8:31ae:7b01:9442:79f1:c7c:81a3? (2001-44b8-31ae-7b01-9442-79f1-0c7c-81a3.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01:9442:79f1:c7c:81a3]) by smtp.gmail.com with ESMTPSA id c7sm13224574pfc.55.2017.10.08.20.02.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Oct 2017 20:02:46 -0700 (PDT) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: svn commit: r451109 - in head: . sysutils sysutils/iocage sysutils/py3-iocage To: Ben Woods Cc: "ports-committers@FreeBSD.org" , svn-ports-all@freebsd.org, svn-ports-head@freebsd.org, "python@freebsd.org" References: <201710030241.v932fWjX078115@repo.freebsd.org> <8tgs-khgn-wny@FreeBSD.org> From: Kubilay Kocak Message-ID: <50094281-0f83-b80c-7991-a8b1208f87f5@FreeBSD.org> Date: Mon, 9 Oct 2017 13:56:10 +1100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Thunderbird/54.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 03:02:49 -0000 On 10/7/17 8:30 PM, Ben Woods wrote: > On 3 October 2017 at 12:01, Jan Beich > wrote: > > Marcelo Araujo writes: > > > Author: araujo > > Date: Tue Oct 3 02:41:32 2017 > > New Revision: 451109 > > URL: https://svnweb.freebsd.org/changeset/ports/451109 > > > > > Log: > > Rename py3-iocage to iocage as by now we don't have more conflicts with > > the old iocage version > > If you mean CONFLICTS = py-iocage-[0-9]* then it never worked as package > comparison failed on underspecificed pyXY- prefix. > > > and also in favor of python flavors that will land soon, it makes > > sense to do it now. > > Wouldn't those conflict with each other unless USE_PYTHON=concurrent ? > > > > > Sponsored by: iXsystems, Inc. > > > > Added: > > head/sysutils/iocage/ > > - copied from r451108, head/sysutils/py3-iocage/ > > Wasn't the python@ way to keep py- prefix in port origin to match pyXY- > prefix in package name? > > foo/bar -> bar > foo/py-bar -> py27-bar ... py36-bar > foo/py2-bar -> py27-bar > foo/py3-bar -> py34-bar, py35-bar, py36-bar > > > > Given that there is only one version of iocage now, and it is not a > library that would ever be depended upon by other python programs, why > does it still need PKGNAMEPREFIX? 'it's , not a library' definition/description is a long outdated distinction. From its conception, it was always imprecise, inconsistent and inconsistently applied (due to its inaccuracy) and incorrect. So too is whether a port can, is or could be depended on. Any number of python language versions can, do, and will always exist, at any point in time, and almost all python packages may, can and almost exclusively do (by consequence of backward compatibility) support > 1 python versions at any time, or any time in the future. > Now that the port is sysutils/iocage, wouldn't it make more sense for > the package to be "iocage" rather than py36-iocage? The prefix-less case can theoretically be relevant or appropriate for software packages that - 'Just happen' to use Python, potentially not in their entirety, AND - Are not Python 'packages (PyPI or packaged in some standard way), AND - Do not use any Python infrastructure (distutils, setuptools, other), AND - Do not, could not or will not *ever* support > 1 (even multiple minor versions within the same major version) Python language versions. By virtue of intrinsic Python code language version compatibility, this is practically never. Further, even if a compelling case can be made, there is no objective downside with prefixing even these software packages, as whether or not the default version has been overridden by the user, the version prefix variable can be always be used, and will be correct for that installation (if it needs to be referenced in other ports, now or into the future). The prefix then is a clue/hint/indication to the user (say in pkg version output), what Python language version the package is connected to, just like every other case. It should also be noted that the existence of prefix-less ports/packages in the tree is not a warrant/reason to create new ones. Instead they should be considered "legacy-named" and brought into compliance/up to standard. Those are the major reasons why prefix-less is now effectively an exclusive allow case, requiring a compelling objective case, and used for a vanishingly smaller (zero in the last N > 3 years) number of cases. Regards, koobs