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.
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
Attachment:
signature.asc
Description: PGP 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
