On Sun, Nov 18, 2018 at 11:00 AM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On 11/17/18 4:09 PM, Orion Poplawski wrote: > > > I'm afraid I'm still very unfamiliar with modules, but it does seem like > > this will be very central to how we deliver packages to EPEL-8. My > > initial questions are: > > Yeah, I don't know them as well as I can, but can take a stab at > answering based on what I know. ;) > > And yes, I agree modules will be key for epel8. > > > > - Can we "simply" extend the platform for current modules to cover > > RHEL-8? That way one could for example deliver octave 4.4 for both > > Fedora and EPEL-8 at the same time. The main issue that I see is > > preventing packages that already exist in RHEL-8 from making it in. > > Yes, we hopefully can do that. However, they might need some adjustment > for epel8 differences. > > The 'existing rhel8 packages' brings up a good point: Do we want to care > about that in epel8 modules? If we replace something thats in a module, > perhaps thats expected and ok, and just avoid replacing base packages? > *my opinion* I think as long modules don't directly compete name and stream with RHEL8's, then it should be ok to build and have as a module in EPEL8. Example: perl 5.26 (can't be in epel8) perl 5.26.FavoriteFlag (can be in epel8) or maybe perl-FavoriteFlag 5.26 (can be in epel8) As far as replacing base packages with modules. My opinion isn't very stong, but here is what I think. I'm against replacing BaseOS packages in modules. I'm ok with replacing AppStream packages in modules. > > - How do we build against the RHEL-8 modules? I see that RHEL-8 has two > > perl and two php module streams: > > > > perl 5.24 minimal, default > > perl 5.26 [d] minimal, default [d] > > php 7.1 devel, minimal, default [d] > > php 7.2 [d] devel, minimal, default [d] > > > > presumably if I want to builld say perl-Config-Simple for EPEL-8 we'll > > need/want to build it for both module streams? How does one go about > > attaching that package to the RHEL-8 module? Or will we need separate > > EPEL versions of the modules? > > If you are building a non modular package, right now you cannot build > against modular packages at all. This is what the 'ursa-major' app that > releng/fesco are discussing enabling will allow for. Until thats setup, > non modular builds can't use any modules. > > If you are building a modular package, you specify in the module yaml > file exactly what modules you are building against and what version. > > - Do we need to distinguish between EPEL packages that will be treated > > much like BaseOS packages in RHEL (very long lived and stable), and ones > > that are like the AppStream (shorter lifetimes)? Do we just want to > > treat everything like AppStream packages? > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/using_application_stream/using-appstream_using-appstream > > I'd say everything like appstream. > > > > > > Some of what I wrote just might not make sense due to my limited > > understanding of modules. > > I could also be wrong above, so hopefully if so someone will correct me. > > kevin > > > > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
