svn commit: r449195 - head/security/py-cryptography

Adam Weinberger adamw at adamw.org
Mon Sep 4 04:31:46 UTC 2017


> On 3 Sep, 2017, at 21:29, Kubilay Kocak <koobs at FreeBSD.org> wrote:
> 
> On 9/3/17 8:28 PM, Rene Ladan wrote:
>> Author: rene
>> Date: Sun Sep  3 10:28:00 2017
>> New Revision: 449195
>> URL: https://svnweb.freebsd.org/changeset/ports/449195
>> 
>> Log:
>>  security/py-cryptography: remove support for expired Python 3.3
>> 
>> Modified:
>>  head/security/py-cryptography/Makefile
>> 
>> Modified: head/security/py-cryptography/Makefile
>> ==============================================================================
>> --- head/security/py-cryptography/Makefile	Sun Sep  3 10:12:26 2017	(r449194)
>> +++ head/security/py-cryptography/Makefile	Sun Sep  3 10:28:00 2017	(r449195)
>> @@ -35,8 +35,6 @@ RUN_DEPENDS+=	${PYTHON_PKGNAMEPREFIX}ipaddress>0:net/p
>> 
>> .if ${PYTHON_REL} < 3300
>> RUN_DEPENDS+=	${PYTHON_PKGNAMEPREFIX}enum34>0:devel/py-enum34
>> -.elif ${PYTHON_REL} < 3400
>> -RUN_DEPENDS+=	${PYTHON_PKGNAMEPREFIX}enum34>0:devel/py3-enum34
>> .endif
>> 
>> post-install:
>> 
> 
> Please revert this change:
> 
> - It is *meant* to include all versions below 3.4, including 2.7
> - It is not necessary to delete when a python language port version is
> removed. The block still semantically and correctly declares the valid
> version dependency requirements from the upstream, independently from
> what the tree has at any point in time.
> 
> Also, if you could, please ask/talk to python maintainers and/or python@
> with regard to port deprecation/deletions before committing. It is not
> always entirely obvious or explicit what is the correct thing to do is
> without fully understanding the versions support and semantics completely.

Python 2.7 needs py-enum34, not py3-enum34, and that block was left in. Unless I'm missing something, René's change should have no impact on python 2.7, no?

The argument against your second point is that sortof-but-not-really supporting expired versions of ports is a disservice to both porters and end-users, when it is unclear what is and isn't expected to work. The precedent these days is that expired ports are purged.

Your final point is well-taken, but I urge you to do the same. EXPIRED purges are tricky, and René makes them happen every month. If ports marked for expiration need to be retained or handled specially, reach out to portmgr!

# Adam


-- 
Adam Weinberger
adamw at adamw.org
https://www.adamw.org




More information about the svn-ports-all mailing list