On Fri, Oct 7, 2022 at 10:54 AM Petr Pisar <ppisar@xxxxxxxxxx> wrote:
>
> V Fri, Oct 07, 2022 at 08:56:41AM -0400, Stephen Smoogen napsal(a):
> > On Fri, 7 Oct 2022 at 03:34, Petr Pisar <ppisar@xxxxxxxxxx> wrote:
> >
> > > V Wed, Sep 28, 2022 at 03:09:32PM -0700, Troy Dawson napsal(a):
> > > > - epel-release will be updated.
> > > > -- epel-modular will set enabled = 0
> > >
> > > Does it only mean releasing a new epel-release package with epel-modular
> > > configuration file set to "enabled = 0", or does it also involve more magic
> > > like editing that configuration with RPM scriptlets.
> > >
> > > I ask because configuration files edited by a user are not subject of RPM
> > > updates. rpm tool installs updated files under a new file name and keeps
> > > the original intact, effectively unupdated.
> > >
> > >
> > My original thought was turning if off for new users, but I am realizing
> > because we defined it to be on by default.. we will be breaking existing
> > users. Thanks for questioning my logic as it was wrong.
> >
> Just confirming that epel-release dist-git reads:
>
> $ grep yum.repos.d/epel-modular.repo epel-release.spec
> %config(noreplace) %{_sysconfdir}/yum.repos.d/epel-modular.repo
>
> To some extent, it won't break existing users:
>
> Those who have never enabled any EPEL module stream will not miss the content.
> They will stop seeing the modules. And that's what we want.
>
> Those who have enabled an EPEL stream because installed packages from it will
> stop seeing the EPEL repository. But they will still keep seeing the enabled
> streams because DNF backed them up at time of enablement and will present them
> as a "@failsafe" repository. These users will be able to inspect and reset
> (= unenable) the streams. Though they won't be able to install or reinstall
> packages from the stream because DNF does not back up the RPM packages.
> I think that's, to some extent, what we want.
One of the biggest problems with modularity in EPEL is the our current
implementation doesn't allow requiring modules from another build
system [0][1]. Has some other third party implementation solved this?
And more importantly, do any third party modules exist that require
EPEL modules?
[0] https://pagure.io/epel/issue/75
[1] https://pagure.io/fedora-infrastructure/issue/8690
>
> Those who have enabled some third-party streams which depend on an EPEL stream
> got the EPEL stream also enabled as a dependency. Hence they will be in the
> same situation as users from the previous paragraph. However, if the
> third-party stream enrolls an update which will require installing a new
> package (or enabling a new EPEL stream) they will get a dependency error.
> This is an unfortunate situation. We only can recommend to the third-party
> supplier to start delivering the stream which has been removed from EPEL.
>
> > There are 2 emailing lists. One of them ate the email that troy sent a
> > while ago and held it versus accepting it. I have kicked the server and
> > hopefully it gets sent now. That said we need to fix the communication and
> > update it for better dates.
> >
> Great. The announce list is a low traffic enough so that user reading Troy's
> message can panic at the intended level.
>
> > We thought of rebuilding all of the existing modules with an updated
> > deprecated somewhere in the data, but since many of them are just branched
> > for each release it looked like we would instead say the module was
> > deprecated in existing Fedora releases. I expect there is a way to do this,
> > but I have no idea what it would break.
> >
> Yeah. The sources are shared across all distributions. I wouldn't dare
> injecting builds for EPEL8 only. MBS has its own pecularities as it concerns
> expanding existing streams resolving the latest module version and that could
> affect building depending modules in Fedora.
>
> > > I worry that users do not follow a list called epel-devel because they
> > > think
> > > it's only for EPEL developers. As such this change will come to them as
> > > a surprise.
> > >
> > >
> > There used to be an epel-users list but about 8 real people subscribed to
> > it versus N hundred spam accounts. We turned it off after most of the posts
> > were needing to be deleted or the few questions being asked were never
> > being answered because the developers were not on it.
> >
> It's a pitty DNF cannot deliver news to users based an installed package.
>
> DNF only can deliver security news based on a fixed package. And to make it
> worse, that feature is unreliable for modular packages because it does not
> transport a stream name.
>
> -- Petr
> _______________________________________________
> 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
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Carl George
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
