• Describe the issue

Issue is there can not be same module:stream in epel8 than there is in rhel8. That's why nodejs:10, nodejs:12 and nginx:1.18 should be removed from epel-modular.

• If we cannot complete your request, what is the impact?

Epel packages override system packages which is not allowed by epel policy.

10:47 < bleve> The problem is: if nodejs:10 module is enabled from AppStream -
it always gets enabled from epel-modular too
13:39 < smooge> bleve if it is happening then modules aren't doing what they
are supposed to do (aka a bug in dnf). especially since
nodejs:10 in EPEL is not a default stream and you shouldn't be
able to mix streams.
13:40 < bleve> smooge: dnf shows both modules enabled.
13:40 < bleve> dnf doesn't have information about repository with module:stream
13:40 < bleve> so there can not be same name in epel
13:41 < bleve> there is no per repo namespace for modules
13:41 < bleve> so nodejs:10 is not possible in epel
13:41 < bleve> and other epel repos have same issue.
13:42 < bleve> epel modules - some of them.
13:42 < smooge> bleve, I think a long form email with what you are seeing and
how to duplicate is probably in order because modularity is
supposed to allow this
13:42 < smooge> they can have the same name but not the same stream
13:42 < bleve> yes - but now they have same stream!
13:42 < bleve> both are nodejs:10
13:42 < bleve> exactly same.
13:43 < bleve> and you are right - different stream would change things.
13:44 < smooge> or maybe they are supposed to have the same stream
13:44 < smooge> god this is a painful mess
18:33 < tdawson> bleve: smooge: Yikes. I see the nodejs issue. That's not
good. Whoever did the epel module shouldn't have had the same
name and stream as RHEL.
18:37 < tdawson> Just read through the policy. We dont' say anything about
having the same stream name. sigh I sorta thought that was
obvious.
18:41 < smooge> tdawson, well I can see where it isn't obvious.. if you go by
the surface claims of modularity.. it would somehow know they
were different
18:42 < smooge> but there is a limit to the magic
18:43 < tdawson> smooge: Ya ... I can see that. What I meant was "I", me,
myself, thought it was obvious. Sometimes when you work with
something all the time, you forget that what you think is
obvious, isn't obvious to everyone.
18:45 < tdawson> smooge: But ya, there were several promises about modularity,
and things that I know I tested, that were taken out and/or
not delivered.
18:47 < tdawson> but now that I've used it for a while, I know what works and
what doesn't, but I also dont' know what's documented and/or
promised and what isn't.
18:49 < orionp> I was going to start looking at creating an EPEL openmpi module
and was going to consult the EPEL guidelines for naming and I
figured that we would have had a convention for naming EPEL
streams. Did we explicitly decide to not have a convention?
18:51 < tdawson> orionp: As far as I know, it didn't come up. The naming of
streams.
18:51 < tdawson> If it did come up, I don't remember.
18:52 < tdawson> I, personally, would have epel in the name. Like 12.epel so
it is easy to notice.
19:08 < orionp> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/HQHFQHMUMQSE2VSQMC7Q2VYAGSDO6P7E/
19:13 < bleve> orionp: yes, but it should be epel-nodejs:10
19:13 < bleve> or nodejs-epel:10
19:14 < bleve> that could be compatible with nodejs:10 from rhel
19:14 < bleve> and have requirement for nodejs:10 - so really add-on module
19:15 < orionp> so these are addons to the rhel nodejs:10 stream?
19:15 < bleve> now problem is that when somebody uses nodejs:10 from distro
they automatically get nodejs:10 from epel - even if they don't
want that.
19:15 < bleve> but actual problem is there is no actual nodejs package in epel
which updates one from rhel
19:15 < bleve> and that should never happen.
19:16 < bleve> so if nodejs:10 is allowed in epel8 it must not update nodejs:10
packages from distro.
19:18 < tdawson> bleve: Well, if I'm reading that email correctly, then the
epel nodejs:10 module, shouldn't be there, because there is
already a RHEL nodejs:10 module.
19:18 < tdawson> The same is true of nodejs:12
19:18 < bleve> I completely agree with you.
19:18 < bleve> I don't see how those could be there.
19:18 < bleve> and same is for nginx:1.18
19:18 < bleve> which is in centos stream now.
19:18 < tdawson> I do see how those got there, at least built ... but not
necessarily pushed through bodhi.
19:19 < bleve> so it is in 8.3
19:19 < tdawson> No, it's in RHEL 8.2
19:19 < bleve> was it?
19:19 < tdawson> Or do you mean nginx:1.18
19:19 < bleve> nginx:1.18
19:20 < bleve> that should be in 8.3 if I didn't mistake
19:20 < tdawson> Oh, you are correct
19:20 < bleve> I'd be ok with nginx:stable being in epel
19:20 < bleve> but module:stream must not be same.
19:21 < bleve> who will clean up this mess?
19:21 < tdawson> bleve: I'm looking at it right now.
19:21 < bleve> tdawson: thank you very much.
19:21 < tdawson> bleve: very welcome
19:22 < tdawson> My desktop wants to update it's nodejs right now, so I have
good motivation to get it cleaned up quickly.
19:22 < bleve> tdawson: that's how I found out the problem.
19:23 < bleve> correct way would be like nodejs-epel:10 which requires nodejs:10
19:23 < bleve> then nodejs-epel:10 could have addons for nodejs:10
19:23 < bleve> or nodejs-addon:10
19:24 < bleve> or whatever - but different module name - not different stream.
19:24 < bleve> like like PowerTools mariadb-devel:10.3 (which is btw missing
mariadb:10 dependency)
19:25 < tdawson> Ya, but looking at the nodejs.yaml file, they are building for
everything, and just blasting it out. They proburbly don't
even know they are building for epel
19:25 < bleve> tdawson: then they must be blocked completely.
19:25 < bleve> epel is so special case.
19:25 < bleve> it must be done separate from fedora.
19:25 < orionp> why couldn't what exists in epel nodejs:10 be nodejs:10-epel ?
The guidelines as written even say that the module name must be
the same as the rhel module name.
19:26 < bleve> orionp: ok. that would mean you'd need to use unsupported
nodejs-10 from nodejs:10-epel to run nodejs
19:23 < bleve> or nodejs-addon:10
19:24 < bleve> or whatever - but different module name - not different stream.
19:24 < bleve> like like PowerTools mariadb-devel:10.3 (which is btw missing
mariadb:10 dependency)
19:25 < tdawson> Ya, but looking at the nodejs.yaml file, they are building for
everything, and just blasting it out. They proburbly don't
even know they are building for epel
19:25 < bleve> tdawson: then they must be blocked completely.
19:25 < bleve> epel is so special case.
19:25 < bleve> it must be done separate from fedora.
19:25 < orionp> why couldn't what exists in epel nodejs:10 be nodejs:10-epel ?
The guidelines as written even say that the module name must be
the same as the rhel module name.
19:26 < bleve> orionp: ok. that would mean you'd need to use unsupported
nodejs-10 from nodejs:10-epel to run nodejs
19:26 < bleve> becuase you can't enable two streams from same module
19:26 < bleve> but if they are different module you can do that.
19:27 < bleve> so if they are nodejs:10 and nodejs-epel:10 you can enable both.
19:27 < orionp> so the epel nodejs:10 module doesn't provide nodejs? I thought
it did?
19:27 < bleve> and nodejs-epel:10 can require nodejs:10
19:27 < bleve> it does but it can't.
19:27 < tdawson> orionp: bleve: It's possible for them to have the same name,
different stream, yes. And I'm going to propose we change the
guideline to say that.
19:27 < bleve> that works too - kind of.
19:28 < bleve> but that also means it can't have default
19:28 < bleve> because if there is nodejs:10 from rhel which is default
19:28 < tdawson> bleve: I believe we need to specifically say that. Because
otherwise this sort of thing happens.
19:28 < bleve> then nodejs:10-epel can't be default
19:28 < tdawson> Correct, the guideline already says epel modules cannot be
enabled by default. That a user has to specifically turn them
on.
19:29 < bleve> hmh. actually problem is now because they are exactly same
module:stream
19:29 < bleve> so default applies to both.
19:31 < tdawson> sgallagh: merlinm: I have a question that hopefully one/both
of you might know the answer to. Regarding modules. If a
yaml file has the platform as [], does that mean it will
always build for epel8? And get pushed out to epel8?
19:31 < tdawson> sgallagh: merlinm: And if that is so, how do we change it? So
that fedora modules don't override RHEL8 modules?
19:32 < bleve> how's nginx:1.18 module? - is there same module in fedora ?
19:33 < bleve> last time I checked there was nginx:stable
19:33 < bleve> but I don't run fedora usually.
19:35 < bleve> tdawson: I guess only way is to requires platform:el8 to build
for epel8?
19:35 < tdawson> bleve: In fedora nginx has "mainline" "1.16" and "1.18"
19:35 < bleve> ok. so that's why conflict.
19:35 < bleve> mainline and stable would make more sense.
19:35 < bleve> yes, I do run nginx and that's their release module.
19:37 < bleve> release model
19:38 < bleve> not release module.
19:39 < bleve> is there a way to block some modules building for epel-modular ?
19:39 < bleve> that way conflicts could be prevented by listing all rhel
modules as "these can't go to epel"
19:48 < tdawson> bleve: That's why I was pinging merlinm and sgallagh. They
would know.
19:48 < bleve> I nowadays understand modulearity limitations quite well.
19:49 < tdawson> I believe it's lunchtime for both of them, so they might not
respond for a little bit.
19:49 < bleve> we developed our own build system for modular packages.
19:49 < sgallagh> tdawson: It means that it will always build for epel8, yes.
It will not be pushed out unless the maintainer submits a
Bodhi update
19:50 < bleve> sgallagh: but problem is that is happening.
19:50 < bleve> sgallagh: there is now three modules which can't be there.
19:50 < sgallagh> err, that shouldn't be possible
19:50 < bleve> nodejs:10, nodejs:12, nginx:1.18
19:50 < sgallagh> buh?
19:51 < sgallagh> And those are ending up in the installable repos?
19:51 < bleve> yes.
19:51 < sgallagh> That is unexpected and undesirable
19:53 < bleve> sgallagh: and the issue is that because nodejs:10 is set to be
19:53 < bleve> sgallagh: and the issue is that because nodejs:10 is set to be
default, if enabled from distro it is also enabled from
epel-modular
19:53 < sgallagh> OK, this was a mistake by zsvetlik
19:54 < bleve> how normal :)
19:55 < bleve> sgallagh: ok. how about nodejs:1.18 ?
19:55 < sgallagh> Same thing for nginx
19:55 < sgallagh> the maintainer submitted it as a Bodhi update
19:55 < sgallagh> Which they should not have done
19:55 < sgallagh> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-MODULAR-2020-06dfcac1ad
19:55 < sgallagh> .fasinfo heffer
19:55 < zodbot> sgallagh: User: heffer, Name: None, email: felix@kaechele.ca,
Creation: 2008-07-04, IRC Nick: None, Timezone: None, Locale:
None, GPG key ID: None, Status: active
19:55 < bleve> how to disable that possibility so that can not happen?
19:55 < zodbot> sgallagh: Approved Groups: cla_fedora cla_done packager
fedorabugs ambassadors cvsl10n cla_fpca l10n
19:55 < sgallagh> Good question
19:55 < sgallagh> I'll defer to nirik or smooge on that.
19:55 < bleve> because instructions won't prevent this.
19:56 < bleve> there must be check in software for not to submit if conflict
with rhel
19:56 < bleve> ok. then the last question: who cleans the mess?
19:57 < sgallagh> bleve: Open a ticket with releng and copy-paste this
conversation in
19:57 < bleve> and who add notify about "no conflicting module:stream" to epel
policy?
19:57 < bleve> sure.
19:58 < sgallagh> In the meantime, I'm going to send a PR to these two modules
to add platform: [-epel8] to the conflicting streams
19:59 < sgallagh> Then they won't even get built anymore
20:01 < sgallagh> bleve: it should already be in the policy
20:01 < sgallagh> The part about not overriding RHEL isn't RPM-specific, I
don't think
20:01 < bleve> sgallagh: tdawson just checked - it is not in policy.
20:02 < tdawson> bleve: sgallagh: I'm working on the policy right now -
https://pagure.io/epel/issue/104
20:03 < bleve> tdawson: looks good.
20:04 < tdawson> Does anyone have a ticket for releng open yet?
20:04 < bleve> not yet.
20:04 < bleve> I'm just searching where to create one :)
20:04 < sgallagh> pagure.io/releng
20:06 < sgallagh> This did get discussed at length previously:
https://www.mail-archive.com/epel-devel@lists.fedoraproject.org/msg06993.html
20:07 < bleve> sgallagh: yes, I now remember reading that.
20:07 < tdawson> sgallagh: Yep. But we forgot to put that bit into the policy.
20:07 < sgallagh> Oops
20:08 < tdawson> But, for this, I don't think the policy would have helped.