> 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. Simon
Stephen John Smoogen
2021-Mar-01 18:14 UTC
[CentOS] Recommendations for webmail client on EL8
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.