| 1 |
On Sat, 14 Mar 2020 19:13:58 +0100 |
| 2 |
Michał Górny <mgorny@g.o> wrote: |
| 3 |
|
| 4 |
> Dear developers, |
| 5 |
> |
| 6 |
> TL;DR: Unless arch teams decide to help us, the Python team will stop |
| 7 |
> supporting non-x86 arches and start dropping non-x86 keywords from |
| 8 |
> reverse dependencies. |
| 9 |
> |
| 10 |
> |
| 11 |
> Python team is struggling with a large number of keywordreqs |
| 12 |
> and stablereqs. It is common for new versions of Python packages to |
| 13 |
> bring new dependencies, and it is uncommon for arch teams to handle our |
| 14 |
> requests in time. |
| 15 |
> |
| 16 |
> The situation is particularly bad on arm64 which seems to have initially |
| 17 |
> stabilized a lot of packages but afterwards can't manage to stabilize |
| 18 |
> new versions. Even with the recent effort of NeddySeagoon, it is still |
| 19 |
> common for me to open new stablereqs while the old ones are waiting for |
| 20 |
> arm64. Overall, arm64 ends up staying behind with dependencies as well |
| 21 |
> which makes each new stablereq more and more effort. |
| 22 |
> |
| 23 |
> However, all non-x86 arches are bad. Making keywordreqs takes |
| 24 |
> tremendous effort, and keeping them up-to-date with frequent package |
| 25 |
> releases is simply impossible. It is quite frustrating when a keyword |
| 26 |
> request is open for a month, then some arch tester points out that |
| 27 |
> the package list is outdated, you spend even more effort updating it, |
| 28 |
> then you wait again and the same situation repeats. |
| 29 |
> |
| 30 |
> In the end, we've reached the point where very high profile packages |
| 31 |
> such as dev-python/virtualenv are missing almost all keywords. To be |
| 32 |
> honest, I don't want to spend another hour trying to update package |
| 33 |
> list, so that *maybe* some arch team will finally consider helping us. |
| 34 |
> |
| 35 |
> For this reason, I propose that the Python team officially stops |
| 36 |
> supporting non-x86 arches. For obvious reasons we will have to continue |
| 37 |
> keeping Portage and the most basic packages work but we will not put any |
| 38 |
> special effort to restore lost keywords, and we will drop keywords from |
| 39 |
> low-profile packages as their dependencies are not keyworded. |
| 40 |
> |
| 41 |
> I am thoroughly frustrated by this state of affairs, and I'm having |
| 42 |
> a serious trouble motivating myself to do anything about it. FWICS |
| 43 |
> others have abandoned the ship earlier. I will probably try to prepare |
| 44 |
> some script to determine where we need to drop keywords, for a start. |
| 45 |
|
| 46 |
I've never joined an arch team as I'm not really interested in stable. |
| 47 |
I understand what you're saying about keyword requests but I didn't |
| 48 |
realise they were also a big issue. |
| 49 |
|
| 50 |
I'm not even keeping up with the work I'm supposed to be doing already |
| 51 |
so I don't exactly want to sign up for more. However, I do have a |
| 52 |
couple of (unstable) arm systems that are important to me so I need to |
| 53 |
keep them running and up to date. Perhaps we could write a tool that |
| 54 |
looks up newer versions of installed ebuilds that have dropped keywords |
| 55 |
for a given arch and report which dependencies also need keywording. I |
| 56 |
guess we don't have something like that? |
| 57 |
|
| 58 |
-- |
| 59 |
James Le Cuirot (chewi) |
| 60 |
Gentoo Linux Developer |
Archives