On 8/26/19 3:33 AM, Petr Pisar wrote:
On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote:
So, I see the following options for how to handle default streams in RHEL 8
Option 1: We disallow assigning default streams at all within EPEL 8.
This will protect us against a future change where RHEL wants to set a
default. Additionally, it means that all EPEL modules are explicitly
opt-in and so we don't ever surprise anyone.
Option 2: We allow making EPEL streams the default stream if RHEL does
not currently provide a default stream. We set strict policy regarding
what a default stream may contain (such as "must not replace any
package provided by RHEL 8"). If RHEL later decides to set a default
for this stream, the RHEL release engineering must ensure that the
`data.version` value is higher than what EPEL 8 carries.
I'm somewhat more in favor of Option 1 here, mostly because it
minimizes the chance of conflicts and ensures the opt-in nature of
EPEL. But I'm willing to hear counter-arguments.
I don't like the Option 1. It makes adding modularized packages into a build
root impossible. Efectivelly forcing everbody to modularize everything or
nothing. That's exactly the deficiency the modularity has in Fedora and does
not have in RHEL. The Option 1 makes the modularity in EPEL terrible as in
Fedora.
Example: RHEL has two perl streams:
perl:5.24
perl:5.26 [d]
You can add a non-modular perl-Foo package into EPEL bacause EPEL magically
adds perl:5.26 into the build root.
If you add a perl-Foo module into EPEL, you won't be able to set a default
stream, hence you won't be able to have it in the build root and therefore you
won't be able to add a non-modular perl-Bar package that requires a perl-Foo
module component into EPEL.
The only solution would be either add perl-Bar as a module, or not add
perl-Foo as a module. If you go the second path (i.e. no modules), it means
you won't be able build none of the packages for the non-default streams (i.e.
perl:5.24).
That effectively pushes modules into the role of leaf-only dependencies.
That's quite awkward situation if you consider that RHEL delivers language
runtimes as modules. The proposed EPEL policy would devalute the non-default
runtimes.
Following up on the perl side of things with an example. What, for
example, would be the recommendation to get postgrey in EPEL8?
It requires perl, but nothing specific to 5.24 or 5.26. It does,
however, have several required perl modules.
It gets a bit more messy if I've got a home grown perl app that
interfaces with SpamAssassin.
If EPEL8 says "just the default stream" for perl, then I have to keep
migrating my app. If every perl module becomes a Modularity Module,
then 'dnf module list' is going to have a nearly endless list of perl
packages, but if modules are only available for one stream, folks are
going to find cpan a bit more friendly.....
Pat
--
Pat Riehecky
Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
