| 1 |
Michał Górny wrote: |
| 2 |
> I'm seriously wondering why I'm wasting so much effort on open source. |
| 3 |
|
| 4 |
Open source only ever works when taking responsibility for one's problems. |
| 5 |
|
| 6 |
|
| 7 |
> I don't see a good way out of it. |
| 8 |
|
| 9 |
I see a couple. Of course all require some effort. |
| 10 |
|
| 11 |
One was already mentioned; move Gentoo package management from Python |
| 12 |
to some compiled language. High effort but maximum independence/reward. |
| 13 |
|
| 14 |
Another option, less effort and less reward, is to investigate how much |
| 15 |
CPython portage in fact requires, and make that a special package in Gentoo. |
| 16 |
|
| 17 |
This essentially means a special-purpose fork of CPython, only for running |
| 18 |
portage. Obviously portage development must then be comfortable without |
| 19 |
using the latest shiny Python language stuff that only future RustPython |
| 20 |
will offer. I guess that's not a problem. |
| 21 |
|
| 22 |
Yet another is a variant on the previous, but even less effort and |
| 23 |
much less reward; freeze what language stuff is allowed in portage code |
| 24 |
and always run portage with some chosen existing/later CPython version. |
| 25 |
|
| 26 |
|
| 27 |
Like libressl and gtk2 this thread also converges on the common point in |
| 28 |
my argumentation: it's not per se bad, and sometimes supremely wise, to |
| 29 |
quit chasing the latest version, and rest on a known platform. |
| 30 |
|
| 31 |
Coupled with independent efforts to place security-relevant parts in |
| 32 |
isolated environments (see sandbox) - ongoing effort regardless of Python - |
| 33 |
I don't see why portage couldn't depend on a CPython interpreter of its own, |
| 34 |
some last version that works well and is then copied and renamed. |
| 35 |
|
| 36 |
It seems like that would be rather straightforward. |
| 37 |
|
| 38 |
It might also be a good thing to take portage out of the overall Gentoo |
| 39 |
Python picture? I don't know here - this bit is just a guess. |
| 40 |
|
| 41 |
|
| 42 |
> arrogant zealots who want to destroy everything in their path |
| 43 |
|
| 44 |
LOL, priceless. |
| 45 |
|
| 46 |
|
| 47 |
> The first big blocker we're going to hit is trustme [3] package that |
| 48 |
> relies on cryptography API pretty heavily to generate TLS certs for |
| 49 |
> testing. |
| 50 |
|
| 51 |
For which testing? Could it be changed to generate certs differently? |
| 52 |
|
| 53 |
CAs aren't magic. Attached is a basic script of mine. |
| 54 |
|
| 55 |
|
| 56 |
//Peter |
Archives