| 1 |
Am Donnerstag, 14. Oktober 2021, 15:40:02 CEST schrieb Marek Szuba: |
| 2 |
> Dear everyone, |
| 3 |
> |
| 4 |
> Following some private discussions, I feel quite strongly now that it |
| 5 |
> would both considerably improve certain processes and make our use of |
| 6 |
> limited manpower more efficient were we to further reduce the number of |
| 7 |
> stable arches in Gentoo Linux. Specifically, I propose to drop |
| 8 |
> - hppa, |
| 9 |
> - sparc, |
| 10 |
> to ~arch-only status. |
| 11 |
> |
| 12 |
> There are IMHO several good reasons for this: |
| 13 |
> - we have got very few people actually supporting these arches, and in |
| 14 |
> case of hppa there is also the hardware bottleneck. Subsequently, |
| 15 |
> stabilisation requests often take a long time to resolve |
| 16 |
> - last but by no means least, my personal experience from the last |
| 17 |
> several years suggests that running ~arch is reasonably trouble-free |
| 18 |
> these days |
| 19 |
> |
| 20 |
> WDYT? |
| 21 |
|
| 22 |
Reducing to what I have a personal opinion about. |
| 23 |
|
| 24 |
For quite a while I have been more or less the arch testing team for hppa and |
| 25 |
sparc, the latter reduced since ago and sam meanwhile utilize even faster |
| 26 |
machines to do much of the the sparc work (yay!). Running these machines is a |
| 27 |
bumpy ride. Things break quite regularly, besides the arch-independent |
| 28 |
breakage like missing dependencies or similar things, which I also find quite |
| 29 |
regularly. |
| 30 |
|
| 31 |
My machines should actually do some useful stuff, like running my Nagios and a |
| 32 |
bunch of nightly builds (CMake, libarchive, things like that). For that, I'd |
| 33 |
like to have the actual system to work. Given the amount of breakage I find |
| 34 |
when doing stabilizations I suspect this is not going to happen. My fear is |
| 35 |
that I'll be rebuilding stuff because there is an upgrade, and then back |
| 36 |
because there was an update, and in between I have to find out what actually |
| 37 |
went wrong. That's close to what I'm doing now, with the difference that the |
| 38 |
main system meanwhile can do it's work because it usually is unaffected, and I |
| 39 |
can decide to ignore the problem for one or another day until I'm bored enough |
| 40 |
to fight the breakage again. |
| 41 |
|
| 42 |
So from my limited PoV this would likely even increase the work that I have to |
| 43 |
do, or the pressure to do it in time to fix the system up to a point where it |
| 44 |
works. |
| 45 |
|
| 46 |
We have already removed many stable packages from hppa, just to reduce the |
| 47 |
amount of work. If sparc really becomes a problem I suspect that dropping most |
| 48 |
of the multimedia or whatever stuff there could also reduce the amount of work |
| 49 |
needed. |
| 50 |
|
| 51 |
Another note: these machines are quite slow, especially the hppa ones, when |
| 52 |
compared with a modern PC with SSD and tons of RAM. I would really _really_ |
| 53 |
welcome it if people could just run tatt for stabilizations on amd64 in a |
| 54 |
regularly empty chroot. It finds tons of stuff with missing dependencies or |
| 55 |
useflags (USE=static is always good for trouble) that I would otherwise run |
| 56 |
into on the slow machines. If you fix only half of the things before it hits |
| 57 |
the minor arches, which is not limited to the above list, it will greatly |
| 58 |
reduce the pain for everyone with a vintage fetish. |
| 59 |
|
| 60 |
So, do what I can't stop you from doing, but at least for me dropping hppa |
| 61 |
will likely not reduce any pain, and if sparc really is a problem than |
| 62 |
dropping some packages will likely do the same thing also. Oh, and maybe mark |
| 63 |
some for fonts and stuff ALLARCHES ;) |
| 64 |
|
| 65 |
Eike (aka Dakon) |
Archives