From: Rolf Eike Beer <eike@sf-mail.de>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only
Date: Fri, 15 Oct 2021 23:40:29 +0200 [thread overview]
Message-ID: <7984758.T7Z3S40VBb@eto.sf-tec.de> (raw)
In-Reply-To: <8404d715-49d4-02a2-1dc9-e936485b7d72@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 3302 bytes --]
Am Donnerstag, 14. Oktober 2021, 15:40:02 CEST schrieb Marek Szuba:
> Dear everyone,
>
> Following some private discussions, I feel quite strongly now that it
> would both considerably improve certain processes and make our use of
> limited manpower more efficient were we to further reduce the number of
> stable arches in Gentoo Linux. Specifically, I propose to drop
> - hppa,
> - sparc,
> to ~arch-only status.
>
> There are IMHO several good reasons for this:
> - we have got very few people actually supporting these arches, and in
> case of hppa there is also the hardware bottleneck. Subsequently,
> stabilisation requests often take a long time to resolve
> - last but by no means least, my personal experience from the last
> several years suggests that running ~arch is reasonably trouble-free
> these days
>
> WDYT?
Reducing to what I have a personal opinion about.
For quite a while I have been more or less the arch testing team for hppa and
sparc, the latter reduced since ago and sam meanwhile utilize even faster
machines to do much of the the sparc work (yay!). Running these machines is a
bumpy ride. Things break quite regularly, besides the arch-independent
breakage like missing dependencies or similar things, which I also find quite
regularly.
My machines should actually do some useful stuff, like running my Nagios and a
bunch of nightly builds (CMake, libarchive, things like that). For that, I'd
like to have the actual system to work. Given the amount of breakage I find
when doing stabilizations I suspect this is not going to happen. My fear is
that I'll be rebuilding stuff because there is an upgrade, and then back
because there was an update, and in between I have to find out what actually
went wrong. That's close to what I'm doing now, with the difference that the
main system meanwhile can do it's work because it usually is unaffected, and I
can decide to ignore the problem for one or another day until I'm bored enough
to fight the breakage again.
So from my limited PoV this would likely even increase the work that I have to
do, or the pressure to do it in time to fix the system up to a point where it
works.
We have already removed many stable packages from hppa, just to reduce the
amount of work. If sparc really becomes a problem I suspect that dropping most
of the multimedia or whatever stuff there could also reduce the amount of work
needed.
Another note: these machines are quite slow, especially the hppa ones, when
compared with a modern PC with SSD and tons of RAM. I would really _really_
welcome it if people could just run tatt for stabilizations on amd64 in a
regularly empty chroot. It finds tons of stuff with missing dependencies or
useflags (USE=static is always good for trouble) that I would otherwise run
into on the slow machines. If you fix only half of the things before it hits
the minor arches, which is not limited to the above list, it will greatly
reduce the pain for everyone with a vintage fetish.
So, do what I can't stop you from doing, but at least for me dropping hppa
will likely not reduce any pain, and if sparc really is a problem than
dropping some packages will likely do the same thing also. Oh, and maybe mark
some for fonts and stuff ALLARCHES ;)
Eike (aka Dakon)
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2021-10-15 21:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-14 13:40 [gentoo-dev] [RFC] Moving more architectures to ~arch only Marek Szuba
2021-10-14 16:08 ` Roy Bamford
2021-10-14 17:10 ` Michał Górny
2021-10-15 6:54 ` Joonas Niilola
2021-10-15 7:20 ` Agostino Sarubbo
2021-10-15 11:59 ` Mikhail Koliada
2021-10-15 21:40 ` Rolf Eike Beer [this message]
2021-10-16 6:17 ` Michał Górny
2021-11-04 18:56 ` Rolf Eike Beer
2021-10-16 21:14 ` William Hubbs
2021-10-18 0:25 ` Thomas Deutschmann
2021-10-18 1:08 ` John Helmert III
2021-10-18 15:09 ` Thomas Deutschmann
2021-10-18 17:07 ` Michał Górny
2021-10-19 15:36 ` Thomas Deutschmann
2021-10-18 17:32 ` Rolf Eike Beer
2021-11-04 18:08 ` Marek Szuba
2021-10-18 0:50 ` Sam James
2021-10-18 0:54 ` Sam James
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7984758.T7Z3S40VBb@eto.sf-tec.de \
--to=eike@sf-mail.de \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox