Am 01.03.21 um 20:21 schrieb Simon Matter:
On Mon, 1 Mar 2021 at 12:46, Simon Matter <simon.mat...@invoca.ch> wrote:
On Mon, 1 Mar 2021 at 10:42, Simon Matter <simon.mat...@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.
RH could help here by providing all missing sub packages (devel etc.).
Not sure about the reasons in not shipping it but for a different
support life cycles or in this case for the absent of support, it can
be communicated, like for Streams, SCL, etc. They have already
different life cycles (compared to BaseOS). If its for delaying OS
rebuilders - well, its wasting just time.
I would build some EPEL packages if I am not forced to rebuild distro
packages just to get the Buildrequires fulfilled. Damm, this was the
main workload in 2019 with RHEL8 GA ...
--
Leon
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
