On Wed, Apr 27, 2022 at 10:26 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Apr 27, 2022 at 10:19 AM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>
> On Wed, Apr 13, 2022 at 2:39 PM Stephen Gallagher <sgallagh(a)redhat.com>
wrote:
> >
> > I've just submitted a review request for separating out NPM into its
> > own package (again). This is being done for a couple reasons:
> >
> > 1) To get rid of the ridiculous release field and take advantage of
> > the %autorelease macro
> > 2) I'm planning to rework how the nodejs packages work to make
> > different versions parallel-installable (with the alternatives
> > infrastructure owning /usr/bin/node). I want to keep NPM in a common
> > location (/usr/lib/node_modules) so that it will work with whatever
> > Node is in use.
>
> I completely missed the most important reason:
> 3) EPEL 9 has announced that it will not support modules, so I want
> there to be some way (aside from the official RHEL releases) to get
> Node.js packages there.
EPEL has said it *can't* support modules, not that it *won't*. There
is a very important distinction here.
Sorry, I was using "won't" in the sense of future tense, not in the
sense of willingness.
Because the Module Build System
cannot build modules on top of remote modules, there's no way to
reliably and correctly produce modular content for EPEL on top of
modular RHEL content.
Starting with Koji 1.28, it's possible to configure build tags to
enable modules:
https://pagure.io/koji/issue/2483
However, MBS still lacks the ability to use this capability:
https://pagure.io/fm-orchestrator/issue/1653
Fix that, and EPEL can build layered modules.
I believe it was more than that, though. It was also a matter of
capacity. I've CCed Troy Dawson to speak more to that. I don't have
the details handy.