Date: Mon, 9 Oct 2017 13:56:10 +1100 From: Kubilay Kocak <koobs@FreeBSD.org> To: Ben Woods <woodsb02@gmail.com> Cc: "ports-committers@FreeBSD.org" <ports-committers@freebsd.org>, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org, "python@freebsd.org" <python@freebsd.org> Subject: Re: svn commit: r451109 - in head: . sysutils sysutils/iocage sysutils/py3-iocage Message-ID: <50094281-0f83-b80c-7991-a8b1208f87f5@FreeBSD.org> In-Reply-To: <CAOc73CD0%2B-zO99nNi48HvR87%2BCWN0DTZ6NeGX3yEHvZUCYLd0w@mail.gmail.com> References: <201710030241.v932fWjX078115@repo.freebsd.org> <8tgs-khgn-wny@FreeBSD.org> <CAOc73CD0%2B-zO99nNi48HvR87%2BCWN0DTZ6NeGX3yEHvZUCYLd0w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/7/17 8:30 PM, Ben Woods wrote: > On 3 October 2017 at 12:01, Jan Beich <jbeich@freebsd.org > <mailto:jbeich@freebsd.org>> wrote: > > Marcelo Araujo <araujo@FreeBSD.org> writes: > > > Author: araujo > > Date: Tue Oct 3 02:41:32 2017 > > New Revision: 451109 > > URL: https://svnweb.freebsd.org/changeset/ports/451109 > <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 <something>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50094281-0f83-b80c-7991-a8b1208f87f5>