1 |
Wednesday 01 Mar 2017 22:14:33, Michał Górny wrote : |
2 |
> Hi, |
3 |
> |
4 |
> So here's a quick summary of what I've established so far about |
5 |
> pycrypto/pycryptodome. |
6 |
> |
7 |
> pycrypto is abandoned and dead since 2013. It was forked into |
8 |
> pycryptodome which is now maintained. The fork is partially compatible |
9 |
> with pycrypto -- though some APIs were removed/replaced. From my quick |
10 |
> experiments, every second random package I tried worked ;-). |
11 |
> |
12 |
> Now, pycryptodome has two modes of install. When it's installed as |
13 |
> 'pycryptodome' it installs 'Crypto' Python package -- which is the same |
14 |
> name as pycrypto used, and is therefore more compatible with packages |
15 |
> using the latter. There is also the alternative 'pycryptodomex' mode |
16 |
> which uses 'CryptoDome' namespace and does not collide with pycrypto. |
17 |
> |
18 |
> For an initial attempt, I've added dev-python/pycryptodome using |
19 |
> the former mode since it was required by a revdep. But it also means |
20 |
> that it blocks pycrypto, and therefore we need to start looking into |
21 |
> adding compatibility with pycryptodome into more packages. |
22 |
> |
23 |
> The problem is, as usual, setuptools/pkg_resources magic. Because even |
24 |
> if a particular app uses APIs that are compatible between the two |
25 |
> packages, pkg_resources will reject to run an app that specifies |
26 |
> 'pycrypto' as a dependency if pycryptodome is installed, and the other |
27 |
> way around. From a quick look at the specification, those dependency |
28 |
> specs don't really support any kind of any-of. |
29 |
> |
30 |
> That is, I think it is reasonable to assume that the only way forward |
31 |
> upstream would be to replace the dependency with 'pycryptodome', |
32 |
> and start requiring the latter. |
33 |
> |
34 |
> As for Gentoo, I think the sanest way forward would be to live with |
35 |
> that. Start testing packages with pycryptodome. If they don't use |
36 |
> pkg_resources and API compatibility can be achieved, add || ( |
37 |
> pycryptodome[...] pycrypto[...] ) if supported. If that is not possible, |
38 |
> a revbump switching to pycryptodome would be reasonable. |
39 |
> |
40 |
> After all, we don't really have many revdeps [1] to port. |
41 |
> |
42 |
> Any other ideas? |
43 |
> |
44 |
> [1]:https://qa-reports.gentoo.org/output/genrdeps/rindex/dev-python/pycrypto |
45 |
> |
46 |
> -- |
47 |
> Best regards, |
48 |
> Michał Górny |
49 |
Hi Michal |
50 |
|
51 |
Thanks for the detailed report and for working on that. |
52 |
|
53 |
I was wondering how you want to go about revbumping those deps. Would you be |
54 |
keen on reviewing a PR which rev bumps a few packages from your list? |
55 |
|
56 |
Cheers |
57 |
|
58 |
-- |
59 |
Patrice Clement |
60 |
Gentoo Linux developer |
61 |
http://www.gentoo.org |