1 |
Hi Michał,
|
2 |
|
3 |
Michał Górny <mgorny@g.o> writes:
|
4 |
|
5 |
> So it seems that upstream has practically closed the discussion, |
6 |
> and the short summary is that they only care for the 'majority' of |
7 |
> users, they don't care for minor platforms (but we're free to port |
8 |
> LLVM/Rust to them) and -- unsurprisingly -- this is a part of crusade |
9 |
> towards promoting Rust. |
10 |
> |
11 |
> Given the aggressive opinions of a number of Python core devs |
12 |
> participating in the discussion, I'm afraid that it is quite probable |
13 |
> that a future version of CPython may require Rust. In fact, they've |
14 |
> already started having knee-jerk reactions to the problem at hand [1]. |
15 |
> To be honest, I've never thought I'd be this disappointed in Python |
16 |
> upstream. |
17 |
> |
18 |
> Good news is that they've promised to keep a LTS branch with security |
19 |
> fixes to the non-Rust version. Until end-of-year. And they've pretty |
20 |
> aggressively stated that they won't fix anything except security bugs |
21 |
> with a CVE assigned. So if it stops building for whatever reason, we're |
22 |
> on our own. |
23 |
> |
24 |
> I've reached out to Debian and they're planning to remove support for |
25 |
> minor architectures for this package in the next release. However, |
26 |
> Python is not as central to them as it is to us. Alpine is also |
27 |
> affected but seems intent on pushing Rust forward, so they'll probably |
28 |
> drop these architectures as well. |
29 |
> |
30 |
> Mike's submitted a PR to remove (unnecessary) cryptography dep from our |
31 |
> urllib3/requests packages [2]. This should make it possible to avoid |
32 |
> cryptography at least on some systems. However, it is still an indirect |
33 |
> test dependency of these packages, so we're going to have a hard time |
34 |
> keeping them properly tested. |
35 |
> |
36 |
> At this point, I'm really depressed about this and I'm seriously |
37 |
> wondering why I'm wasting so much effort on open source. I don't see |
38 |
> a good way out of it. Rust could be a nice language -- but it won't if |
39 |
> it continues to be surround by arrogant zealots who want to destroy |
40 |
> everything in their path towards promoting it. |
41 |
> |
42 |
> The first big blocker we're going to hit is trustme [3] package that |
43 |
> relies on cryptography API pretty heavily to generate TLS certs for |
44 |
> testing. If we managed to convince upstream to support an alternate |
45 |
> crypto backend, we'd be able to retain minor keywords a lot of packages |
46 |
> without too much pain. |
47 |
|
48 |
I could feel the pain.
|
49 |
|
50 |
Bootstraping Rust on Prefix is somewhere between alpha, hppa, ia64,
|
51 |
m68k, s390 and amd64[1]. The problem was exposed by
|
52 |
gnome-base/librsvg[2].
|
53 |
|
54 |
I am wondering how useable pkgcore is on alpha, hppa, etc. Maybe it's
|
55 |
time for us to plan for a Gentoo without essential Python dependency.
|
56 |
|
57 |
Looking forward to gcc-rust for saving the world in the end.
|
58 |
|
59 |
Benda
|
60 |
|
61 |
1. https://bugs.gentoo.org/689160
|
62 |
2. https://bugs.gentoo.org/739574 |