[EPEL-devel] Re: EPEL-8 plans and needed work
On Sun, Nov 18, 2018 at 11:00 AM Kevin Fenzi 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.1devel, 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@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[EPEL-devel] Re: EPEL-8 plans and needed work
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? > - 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 signature.asc Description: OpenPGP digital signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
[EPEL-devel] Re: EPEL-8 plans and needed work
On 11/16/18 4:00 PM, Stephen John Smoogen wrote: Yesterday, Red Hat announced its Red Hat Enterprise Linux 8 Beta, and so we would like to start getting ideas on what people expect for EPEL-8. First off, we are not going to be able to do this like we did with EPEL-5,6, or 7 because too much of the build infrastructure and tools have changed since 2013 when we last started planning for EPEL-7. Packages no longer have per branch permissions, packages can be ‘by themselves’ and also modules, and modules really need more than one packager to maintain run them. Plus we all know that there are points of pain in the current EPEL structure where packages go and come from the repository without much notice or planning. I would like to open the floor on how a beta program this time should be run and also how EPEL in the future should compose itself (currently we completely compose daily without an update tree or other tools) in the future. I would like any ideas to come with some proposals on how it could be implemented (can be hand-wavy), and I would like to ‘close’ debate on this by December 15th with a plan to have a beta ready to start building in January. As that may be a long delay for people who need openvpn and such, I would like to look also at standing up a mini-epel in /pub/alt which could be used to put packages in for users built using the methods we currently use. This area would also be where attempts to make EPEL-8 and anything else we do more modular would be done without affecting core EPEL until we are ready to make it happen. 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: - 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. - 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.1devel, 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? - 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 Some of what I wrote just might not make sense due to my limited understanding of modules. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
