On Thu, Feb 25, 2021 at 7:31 AM Stephen John Smoogen <smooge at gmail.com> wrote:> On Thu, 25 Feb 2021 at 02:11, Simon Matter <simon.matter at invoca.ch> wrote: > > > >> > > >> Smooge, you know I feel your pain, but becoming a maintainer in EPEL > has > > >> a pretty high bar (lots of new tools and methods to work with, amongst > > >> other things) -- as it SHOULD, given that it's intended as an addon to > > >> EL and needs to be very tightly controlled. It's just more difficult > to > > >> get started these days relative to when anyone could build an rpm as > > >> long as they had a copy of Maximum RPM and knew how to drive 'rpm -ba' > > >> .... back when building as root in a non-reproducible buildroot > wasn't a > > >> cardinal sin..... > > >> > > > > > > Not that it matters .. BUT .. EL8 is much harder to build for. There > > > are modular components, not all the Devel files exist, etc. > > > > > > It is much harder than EL7. > > > > Thanks Johnny for reminding. I was wondering why the situation for EL8 is > > so much worse than for EL7 and that was true before CentOS Stream came > up. > > > > In the end I have never been happy with the new modules system and how it > > makes packaging much more difficult than it was and than it should be. > > > > IMHO the hurdles to build high quality packages should be as simple as > > possible but the difficulties to do so went in the wrong direction. The > > result we see now. Today we have an unstable distribution (Fedora) with a > > quite good and comprehensive package set, and we have stable (EL) with an > > unstable and lacking package set. > > > > > Even without modules (A person wrote a program which undid some of those > problems for us in EPEL), EL8 is not easy to build. Packages and software > themselves have gotten more interdependent and complex. This leads to a > larger and larger chain of 'buildrequires' and 'requires' for each package. > To get some of the XFCE packages into EPEL you need to bring into EPEL all > kinds of quaternary packages so you can build the tertiary packages which > are needed for the secondary packages which allow you to get something like > xfce4-cpufreq-plugin-1.2.1-7.fc33.src.rpm built. Each of those packages > needs a maintainer who wants to deal with them in EPEL which requires them > to run an EL to test. > > I tried an experiment during the RHEL-8 beta to see what it would take to > get EPEL-8 1:1 with EPEL-7.. I gave up after adding nearly a thousand > packages to the 'build chain' which were not in EPEL-7 nor even in the > RHEL-8 beta or its 'buildroot'. These were mainly packages that are in > Fedora already and would need to be maintained in EPEL and no one wants to > do that. > > This was supposed to be a problem modularity was to fix.. so you need 100 > packages not in EPEL for your 1 application set, and you don't want to > maintain those extra packages? Just put them inside your module build chain > and deliver what you wanted. Of course that is still a monumental task and > most packagers would say 'meh I got better things to do, like do a root > canal without anesthesia.' > > > > > Simon > > > > _______________________________________________ > > CentOS mailing list > > CentOS at centos.org > > https://lists.centos.org/mailman/listinfo/centos > > > > > -- > Stephen J Smoogen. > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centosDoes package building for debian and derivatives not run into this same issue of interdependency? Is it because they have more packages to begin with? Not judging, I'm curious. Tony Schreiner
> On Thu, Feb 25, 2021 at 7:31 AM Stephen John Smoogen <smooge at gmail.com> > wrote: > >> On Thu, 25 Feb 2021 at 02:11, Simon Matter <simon.matter at invoca.ch> >> wrote: >> >> > >> >> > >> Smooge, you know I feel your pain, but becoming a maintainer in >> EPEL >> has >> > >> a pretty high bar (lots of new tools and methods to work with, >> amongst >> > >> other things) -- as it SHOULD, given that it's intended as an addon >> to >> > >> EL and needs to be very tightly controlled. It's just more >> difficult >> to >> > >> get started these days relative to when anyone could build an rpm >> as >> > >> long as they had a copy of Maximum RPM and knew how to drive 'rpm >> -ba' >> > >> .... back when building as root in a non-reproducible buildroot >> wasn't a >> > >> cardinal sin..... >> > >> >> > > >> > > Not that it matters .. BUT .. EL8 is much harder to build for. >> There >> > > are modular components, not all the Devel files exist, etc. >> > > >> > > It is much harder than EL7. >> > >> > Thanks Johnny for reminding. I was wondering why the situation for EL8 >> is >> > so much worse than for EL7 and that was true before CentOS Stream came >> up. >> > >> > In the end I have never been happy with the new modules system and how >> it >> > makes packaging much more difficult than it was and than it should be. >> > >> > IMHO the hurdles to build high quality packages should be as simple as >> > possible but the difficulties to do so went in the wrong direction. >> The >> > result we see now. Today we have an unstable distribution (Fedora) >> with a >> > quite good and comprehensive package set, and we have stable (EL) with >> an >> > unstable and lacking package set. >> > >> > >> Even without modules (A person wrote a program which undid some of those >> problems for us in EPEL), EL8 is not easy to build. Packages and >> software >> themselves have gotten more interdependent and complex. This leads to a >> larger and larger chain of 'buildrequires' and 'requires' for each >> package. >> To get some of the XFCE packages into EPEL you need to bring into EPEL >> all >> kinds of quaternary packages so you can build the tertiary packages >> which >> are needed for the secondary packages which allow you to get something >> like >> xfce4-cpufreq-plugin-1.2.1-7.fc33.src.rpm built. Each of those packages >> needs a maintainer who wants to deal with them in EPEL which requires >> them >> to run an EL to test. >> >> I tried an experiment during the RHEL-8 beta to see what it would take >> to >> get EPEL-8 1:1 with EPEL-7.. I gave up after adding nearly a thousand >> packages to the 'build chain' which were not in EPEL-7 nor even in the >> RHEL-8 beta or its 'buildroot'. These were mainly packages that are in >> Fedora already and would need to be maintained in EPEL and no one wants >> to >> do that. >> >> This was supposed to be a problem modularity was to fix.. so you need >> 100 >> packages not in EPEL for your 1 application set, and you don't want to >> maintain those extra packages? Just put them inside your module build >> chain >> and deliver what you wanted. Of course that is still a monumental task >> and >> most packagers would say 'meh I got better things to do, like do a root >> canal without anesthesia.' >> >> >> >> > Simon >> > >> > _______________________________________________ >> > CentOS mailing list >> > CentOS at centos.org >> > https://lists.centos.org/mailman/listinfo/centos >> > >> >> >> -- >> Stephen J Smoogen. >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos > > > Does package building for debian and derivatives not run into this same > issue of interdependency? Is it because they have more packages to begin > with? > Not judging, I'm curious. > > Tony SchreinerBoth Debian and Fedora have a much larger package base and try to keep those alive step by step. EL on the other side has a very limited, supported package set and therefore a lot of packages needed to build a lot of packages are just missing. It's my impression that most development power goes into the limited base system and cloud, container and all the newer fancy stuff. Simon
On Thu, 25 Feb 2021 at 08:18, Tony Schreiner <anthony.schreiner at bc.edu> wrote:> On Thu, Feb 25, 2021 at 7:31 AM Stephen John Smoogen <smooge at gmail.com> > wrote: > > > On Thu, 25 Feb 2021 at 02:11, Simon Matter <simon.matter at invoca.ch> > wrote: > > > > > >> > > > >> Smooge, you know I feel your pain, but becoming a maintainer in EPEL > > has > > > >> a pretty high bar (lots of new tools and methods to work with, > amongst > > > >> other things) -- as it SHOULD, given that it's intended as an addon > to > > > >> EL and needs to be very tightly controlled. It's just more > difficult > > to > > > >> get started these days relative to when anyone could build an rpm as > > > >> long as they had a copy of Maximum RPM and knew how to drive 'rpm > -ba' > > > >> .... back when building as root in a non-reproducible buildroot > > wasn't a > > > >> cardinal sin..... > > > >> > > > > > > > > Not that it matters .. BUT .. EL8 is much harder to build for. There > > > > are modular components, not all the Devel files exist, etc. > > > > > > > > It is much harder than EL7. > > > > > > Thanks Johnny for reminding. I was wondering why the situation for EL8 > is > > > so much worse than for EL7 and that was true before CentOS Stream came > > up. > > > > > > In the end I have never been happy with the new modules system and how > it > > > makes packaging much more difficult than it was and than it should be. > > > > > > IMHO the hurdles to build high quality packages should be as simple as > > > possible but the difficulties to do so went in the wrong direction. The > > > result we see now. Today we have an unstable distribution (Fedora) > with a > > > quite good and comprehensive package set, and we have stable (EL) with > an > > > unstable and lacking package set. > > > > > > > > Even without modules (A person wrote a program which undid some of those > > problems for us in EPEL), EL8 is not easy to build. Packages and software > > themselves have gotten more interdependent and complex. This leads to a > > larger and larger chain of 'buildrequires' and 'requires' for each > package. > > To get some of the XFCE packages into EPEL you need to bring into EPEL > all > > kinds of quaternary packages so you can build the tertiary packages which > > are needed for the secondary packages which allow you to get something > like > > xfce4-cpufreq-plugin-1.2.1-7.fc33.src.rpm built. Each of those packages > > needs a maintainer who wants to deal with them in EPEL which requires > them > > to run an EL to test. > > > > I tried an experiment during the RHEL-8 beta to see what it would take to > > get EPEL-8 1:1 with EPEL-7.. I gave up after adding nearly a thousand > > packages to the 'build chain' which were not in EPEL-7 nor even in the > > RHEL-8 beta or its 'buildroot'. These were mainly packages that are in > > Fedora already and would need to be maintained in EPEL and no one wants > to > > do that. > > > > This was supposed to be a problem modularity was to fix.. so you need 100 > > packages not in EPEL for your 1 application set, and you don't want to > > maintain those extra packages? Just put them inside your module build > chain > > and deliver what you wanted. Of course that is still a monumental task > and > > most packagers would say 'meh I got better things to do, like do a root > > canal without anesthesia.' > > > > Does package building for debian and derivatives not run into this same > issue of interdependency? Is it because they have more packages to begin > with? > Not judging, I'm curious. > >They run into the same interdependency.. but because they have organically grown their distro every day, those dependencies grew 1 at a time. For EPEL and other EL repos you have to jump multiple Fedora releases to catch up. So in EL6 we were Fedora Linux 12. In EL7.0 we had to jump and rebuild from scratch a lot of Fedora Linux 18 and Fedora Linux 19 and then progressed up to about Fedora 24 as various parts got rebased and upgraded to 7.9. For EL8, we have to jump to Fedora Linux 28 and then each dot release rebase parts while keeping other parts back because rebasing is focused. [This means that if something needs glibc-2.32 you can't put it in EL8 without a lot of patching to make it work with whatever changed... but some other related components may be able to recompile fine.] Thus you need people who enjoy that kind of work to do this because EPEL is nearly all volunteer work. I had to work after hours or take vacation time to work on getting EPEL-8 out so that I could get focused effort on it. Most people don't have that 'luxury' and so the number of volunteers is small but the expectation that it will be there is large.> Tony Schreiner > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >-- Stephen J Smoogen.