Re: git: f5711e95bcd1 - main - security/py-cryptography: Update to 38.0.1

On 09/10/22 23:04, Charlie Li wrote:
> Yasuhiro Kimura wrote:
>> Subject: git: f5711e95bcd1 - main - security/py-cryptography: Update 
>> to 38.0.1
>> Date: Sun, 9 Oct 2022 15:40:07 GMT
>>
>>> The branch main has been updated by sunpoet:
>>>
>>> URL: 
>>> https://cgit.FreeBSD.org/ports/commit/?id=f5711e95bcd17b154bdd697cb3f1650a788fdf3c
>>>
>>> commit f5711e95bcd17b154bdd697cb3f1650a788fdf3c
>>> Author:     Po-Chuan Hsieh <sunpoet@FreeBSD.org>
>>> AuthorDate: 2022-10-09 15:32:23 +0000
>>> Commit:     Po-Chuan Hsieh <sunpoet@FreeBSD.org>
>>> CommitDate: 2022-10-09 15:37:58 +0000
>>>
>>>      security/py-cryptography: Update to 38.0.1
[...]
>>
> Because having the Rust bits available is not optional after 3.4, ie 
> required in 35 and later.
> 
> The proper solution is having the oxidised version (35 and later) as a 
> separate port and this one remaining on 3.4 with backports as needed, 
> with selectable DEFAULT_VERSIONS, similar to graphics/librsvg2{,-rust}, 
> especially to appease those who have to build in QEMU_EMULATING 
> (including some of our own official package builders), since Rust itself 
> won't build there like that. Otherwise say goodbye to many many Python 
> packages and consumers built in QEMU_EMULATING.
> 

Anyway something should be done about this. A lot of things are broken 
at runtime. py-certbot, ansible, also awscli (this one requires a 
further update to py-openssl to actually work), others I can't remember 
right now or I've not heard about still.

There is a bug report with a patch making this port correctly compile 
the rust bits and work as expected: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853

The issue and some fallout is being extensively discussed in 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266937

The fastest path to make things work for most users would be to just 
enable rust parts right away in the port as is, using the patch from bug 
#254853

I understand there are further needs due to the limited(or lack thereof) 
support from rust for many architectures, so I have no objections to 
giving an escape hatch, but the default should be to follow the latest 
version.

I'm in no real hurry and do not press for a fast solution, but it would 
be a good thing for all the consumers to know if the maintainer is 
working on this, and what solution he's going to pursue. knowing that, 
we all know doing things takes time, which is a scarce resource, so 
having to wait some for the execution would be no issue at all.

-- 
Guido Falsi <madpilot@FreeBSD.org>