[CentOS] Recommendations for webmail client on EL8

Mon Mar 1 19:21:18 UTC 2021
Simon Matter <simon.matter at invoca.ch>

> 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.

Are they Red Hat paid people? If so it confirms my impression that EPEL is
not seen very important by Red Hat.

> 2) Usage has grown greatly with the expectation that what is in EL6 will
> be
> in EL7 will be in EL8.

As I did and still do a lot of packages which should build on multiple EL
versions, I now that it's also a result of the big changes between EL6 and
EL7 with the move to systemd. It has resulted in a LOT of additional work
for packagers and maybe some got tired a bit. I did at least.

> 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.

Some of it is also selfmade. New init system, changing packaging rules,
new required build tools, tricky new modularity to just name a few. Other
systems like the different BSD ports show that it could be made easier.

> 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.]

Here is probably the biggest problem: a lot of packages are made for
Fedora. Then, when EL is forked from Fedora, all additional packages seem
to get stripped off. Later, when EL becomes available, some kind soul has
to reimplement what has been stripped off before. Doesn't reality come
close here?

> 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.

To me this seems like a security nightmare - like closed sorce.

> 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

I know what you mean but IMHO the real problem is that bulding good
packages became too complicated. In your list above you forgot that you
also have to care about SELinux and other nice things.

My biggest concern is how this is going to be fixed? Are there any plans
from anyone?

Simon