[CentOS] Recommendations for webmail client on EL8

Mon Mar 1 18:14:24 UTC 2021
Stephen John Smoogen <smooge at gmail.com>

On Mon, 1 Mar 2021 at 12:46, Simon Matter <simon.matter at invoca.ch> wrote:

> > On Mon, 1 Mar 2021 at 10:42, Simon Matter <simon.matter at invoca.ch>
> wrote:
> >
> >> > Am 01.03.21 um 15:56 schrieb Simon Matter:
> >>
> >> >> Thanks for your suggestion. No, I'm not really thinking about
> >> >> docker/podman. I prefer having clean system installs, even if I have
> >> to
> >> >> create RPMs myself. This has worked fine for the last two decades but
> >> >> yes,
> >> >> I'm afraid, this is considered old school these days :-)
> >> >>
> >> >
> >> > Hey Simon, take a look at Remi's repository ...
> >> >
> >> > --
> >> > Leon
> >>
> >> Hi Leon, thanks.
> >> I'm wondering why these things are not in EPEL?
> >>
> >>
> > Because building with modules in EPEL is very limited. I think
> > https://pagure.io/epel/issue/75 covers many of the issues and the
> > frustration of dealing with them.
> >
> I found this link last Saturday but didn't want to give up too quickly.
> I wasn't aware that the situation with EPEL8 is so bad because a) we just
> started migrating systems to CentOS 8 when the bad news came some weeks
> ago about CentOS, and b) because we mostly built our own RPMs and didn't
> depend on EPEL in the past.
> Now that building became more difficult with the new modularity, it seemed
> a good thing to rely more on EPEL - just to discover that EPEL is also
> lacking so much in 8.
EPEL has always been in the need of more people who can volunteer time to
help maintain and package things. However for the last 5 years (so even
before EL8) the need has gotten worse:
1) The core maintainers who pushed EL6 and EL7 have been increasingly
'retired to management' at their respective jobs.
2) Usage has grown greatly with the expectation that what is in EL6 will be
in EL7 will be in EL8.
3) Package complexity has grown exponentially. You need more and more
packages in the repo as 'buildrequires' or 'install' but are not 'leaf
nodes' like say squirrelmail.
4) Most people who 'maintain' the package in Fedora see that as a full time
job already and dealing with EPEL issues/complaints is added unpaid work
they don't care less for. [For some reason a good many people who open bugs
for EPEL packages expect the same level of support as they would for a paid
for enterprise product.. and feel like being jerks is the way to get that
from EPEL.]
5) Many upstreams have gone whole-hog into containers and will only work
with/deal with the set of tools in their container versus in RPMs or debs.
They are especially that way for laggard operating systems like Enterprise
Linux or LTS versions.
6) Building *good rpms is hard. Building *good modules is harder. However
building *good containers makes modularity look easy. So it is easier to
just grab someone elses and YOLO.

*good = a package which is reproducible, upgradable, secure, debugable,
maintainable and probably 10 other features everyone silently expects from
EPEL packages versus some one who did a tar2rpm

Stephen J Smoogen.