Re: Modularity Policy Discussion for EPEL 8.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/26/19 2: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.

-- Petr

What if we could have "slave" modules? I.e. "epel-perl" that would acquire the state of the "perl" module and could contain the EPEL perl packages. This would require coordination among the EPEL perl packagers to maintain the epel-perl module but would also allow it to automatically track the state of the RHEL module - and allow it to have a default stream.


--
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion@xxxxxxxx
Boulder, CO 80301                 https://www.nwra.com/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
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

[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux