Ansible in EPEL 9

[Maxwell G]

Hello EPEL users and developers,


RHEL 9.2 was released today,
so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL
9.2's ansible-core bump from 2.13.3 to 2.14.2.
Each ansible major version is tied to a specific major version of
ansible-core, and we keep them in sync.

Along with this change, RHEL 9.2 builds ansible-core for the python3.11
stack instead of the default python3 (3.9) stack.
Therefore, ansible in EPEL now built for python3.11 as well.

Here is the Bodhi update:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1
Please help test and give karma.

Until this update is pushed to stable, you may receive an error like
this when running dnf upgrade

```
Error:
 Problem: package ansible-6.3.0-2.el9.noarch requires python3.9dist(ansible-core) >=
2.13.3, but none of the providers can be installed
  - cannot install both ansible-core-2.14.2-4.el9.x86_64 and
ansible-core-2.13.3-2.el9_1.x86_64
  - cannot install both ansible-core-2.14.2-4.el9.x86_64 and
ansible-core-2.13.3-1.el9.x86_64
  - cannot install the best update candidate for package
ansible-core-2.13.3-2.el9_1.x86_64
  - cannot install the best update candidate for package ansible-6.3.0-2.el9.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or
'--skip-broken' to skip uninstallable packages or '--nobest' to use not
only best candidate packages)
```

There are a couple potential solutions:

1. Run
     $ dnf upgrade --exclude ansible-core
   to skip ansible-core and upgrade everything else.
2. In a couple hours from from now (now is 3:15 UTC), you'll be able to install
   ansible 7.2.0 from testing with
     $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core
   and then run a plain `dnf upgrade` as usual.


--
Happy automating,


Maxwell G (@gotmax23)
Pronouns: He/They

[Josh Boyer]

On Tue, May 9, 2023 at 11:24 PM Maxwell G <maxwell(a)gtmx.me&gt; wrote:
>  Hello EPEL users and developers,
>
>
>  RHEL 9.2 was released today,
>  so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL
>  9.2's ansible-core bump from 2.13.3 to 2.14.2.
>  Each ansible major version is tied to a specific major version of
>  ansible-core, and we keep them in sync.
>
>  Along with this change, RHEL 9.2 builds ansible-core for the python3.11
>  stack instead of the default python3 (3.9) stack.
>  Therefore, ansible in EPEL now built for python3.11 as well.
>
>  Here is the Bodhi update:
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1
>  Please help test and give karma. 
Thank you for your efforts and clear communication!  It is very much
appreciated.

josh

>  Until this update is pushed to stable, you may receive an error like
>  this when running dnf upgrade
>
>  ```
>  Error:
>   Problem: package ansible-6.3.0-2.el9.noarch requires python3.9dist(ansible-core) >=
> 2.13.3, but none of the providers can be installed
>    - cannot install both ansible-core-2.14.2-4.el9.x86_64 and
> ansible-core-2.13.3-2.el9_1.x86_64
>    - cannot install both ansible-core-2.14.2-4.el9.x86_64 and
> ansible-core-2.13.3-1.el9.x86_64
>    - cannot install the best update candidate for package
> ansible-core-2.13.3-2.el9_1.x86_64
>    - cannot install the best update candidate for package ansible-6.3.0-2.el9.noarch
>  (try to add '--allowerasing' to command line to replace conflicting packages or
> '--skip-broken' to skip uninstallable packages or '--nobest' to use not
> only best candidate packages)
>  ```
>
>  There are a couple potential solutions:
>
>  1. Run
>       $ dnf upgrade --exclude ansible-core
>     to skip ansible-core and upgrade everything else.
>  2. In a couple hours from from now (now is 3:15 UTC), you'll be able to install
>     ansible 7.2.0 from testing with
>       $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core
>     and then run a plain `dnf upgrade` as usual.
>
>
>  --
>  Happy automating,
>
>
>  Maxwell G (@gotmax23)
>  Pronouns: He/They
>  _______________________________________________
>  epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Leon Fauster]

Am 10.05.23 um 05:24 schrieb Maxwell G:
>  Hello EPEL users and developers,
>  
>  
>  RHEL 9.2 was released today,
>  so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL
>  9.2's ansible-core bump from 2.13.3 to 2.14.2.
>  Each ansible major version is tied to a specific major version of
>  ansible-core, and we keep them in sync.
>  
>  Along with this change, RHEL 9.2 builds ansible-core for the python3.11
>  stack instead of the default python3 (3.9) stack.
>  Therefore, ansible in EPEL now built for python3.11 as well.
>  
>  Here is the Bodhi update:
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1
>  Please help test and give karma.
>  
>  Until this update is pushed to stable, you may receive an error like
>  this when running dnf upgrade
>  
>  ```
>  Error:
>    Problem: package ansible-6.3.0-2.el9.noarch requires python3.9dist(ansible-core) >=
> 2.13.3, but none of the providers can be installed
>     - cannot install both ansible-core-2.14.2-4.el9.x86_64 and
> ansible-core-2.13.3-2.el9_1.x86_64
>     - cannot install both ansible-core-2.14.2-4.el9.x86_64 and
> ansible-core-2.13.3-1.el9.x86_64
>     - cannot install the best update candidate for package
> ansible-core-2.13.3-2.el9_1.x86_64
>     - cannot install the best update candidate for package ansible-6.3.0-2.el9.noarch
>  (try to add '--allowerasing' to command line to replace conflicting packages or
> '--skip-broken' to skip uninstallable packages or '--nobest' to use not
> only best candidate packages)
>  ```
>  
>  There are a couple potential solutions:
>  
>  1. Run
>        $ dnf upgrade --exclude ansible-core
>      to skip ansible-core and upgrade everything else.
>  2. In a couple hours from from now (now is 3:15 UTC), you'll be able to install
>      ansible 7.2.0 from testing with
>        $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core
>      and then run a plain `dnf upgrade` as usual.
>   

While setting up a new workstation with an EL rebuild, I run into the 
situation that ansible is not installable (rocky still on 9.1). Is there
a change from EPEL side to close this time gap by at least keep older 
packages (current-1) on the repos? Like epel-next closes the "forward" 
gap, this would close such "backward" gap, thought ...

--
Leon

[Jonathan Wright]

EPEL tracks RHEL, not clones.

EPEL10 is likely to resolve this, however.  Ref
https://discussion.fedoraproject.org/t/epel-10-proposal

On Mon, May 15, 2023 at 1:31 PM Leon Fauster via epel-devel <
epel-devel(a)lists.fedoraproject.org&gt; wrote:

>  Am 10.05.23 um 05:24 schrieb Maxwell G:
>  > Hello EPEL users and developers,
>  >
>  >
>  > RHEL 9.2 was released today,
>  > so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL
>  > 9.2's ansible-core bump from 2.13.3 to 2.14.2.
>  > Each ansible major version is tied to a specific major version of
>  > ansible-core, and we keep them in sync.
>  >
>  > Along with this change, RHEL 9.2 builds ansible-core for the python3.11
>  > stack instead of the default python3 (3.9) stack.
>  > Therefore, ansible in EPEL now built for python3.11 as well.
>  >
>  > Here is the Bodhi update:
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1
>  > Please help test and give karma.
>  >
>  > Until this update is pushed to stable, you may receive an error like
>  > this when running dnf upgrade
>  >
>  > ```
>  > Error:
>  >   Problem: package ansible-6.3.0-2.el9.noarch requires
>  python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be
>  installed
>  >    - cannot install both ansible-core-2.14.2-4.el9.x86_64 and
>  ansible-core-2.13.3-2.el9_1.x86_64
>  >    - cannot install both ansible-core-2.14.2-4.el9.x86_64 and
>  ansible-core-2.13.3-1.el9.x86_64
>  >    - cannot install the best update candidate for package
>  ansible-core-2.13.3-2.el9_1.x86_64
>  >    - cannot install the best update candidate for package
>  ansible-6.3.0-2.el9.noarch
>  > (try to add '--allowerasing' to command line to replace conflicting
>  packages or '--skip-broken' to skip uninstallable packages or '--nobest'
> to
>  use not only best candidate packages)
>  > ```
>  >
>  > There are a couple potential solutions:
>  >
>  > 1. Run
>  >       $ dnf upgrade --exclude ansible-core
>  >     to skip ansible-core and upgrade everything else.
>  > 2. In a couple hours from from now (now is 3:15 UTC), you'll be able to
>  install
>  >     ansible 7.2.0 from testing with
>  >       $ dnf upgrade --refresh --enablerepo=epel-testing ansible
>  ansible-core
>  >     and then run a plain `dnf upgrade` as usual.
>  >
>
>
>  While setting up a new workstation with an EL rebuild, I run into the
>  situation that ansible is not installable (rocky still on 9.1). Is there
>  a change from EPEL side to close this time gap by at least keep older
>  packages (current-1) on the repos? Like epel-next closes the "forward"
>  gap, this would close such "backward" gap, thought ...
>
>  --
>  Leon
>
>
>  _______________________________________________
>  epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]...
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

[Leon Fauster]

Am 15.05.23 um 20:50 schrieb Jonathan Wright:
>  EPEL tracks RHEL, not clones.
>  
>  EPEL10 is likely to resolve this, however.  Ref 
>  https://discussion.fedoraproject.org/t/epel-10-proposal 
>  <https://discussion.fedoraproject.org/t/epel-10-proposal>
>  
>  On Mon, May 15, 2023 at 1:31 PM Leon Fauster via epel-devel  
...
>  
>  
>      While setting up a new workstation with an EL rebuild, I run into the
>      situation that ansible is not installable (rocky still on 9.1). Is there
>      a chance from EPEL side to close this time gap by at least keep older
>      packages (current-1) on the repos? Like epel-next closes the "forward"
>      gap, this would close such "backward" gap, thought ...
>  
>      --
>      Leon 

Well, my point was not a strategy change, more a technical variation
that eliminates a lot of cases (also the above mentioned). Without
a single downgrade path, regressions can not be addressed. Just an
example: https://bugzilla.redhat.com/show_bug.cgi?id=2184351

So, it was a general feasibility request. For those that slip into
such situation; there are still the repo archives, that get a copy
when a minor release happens (this one I had forgotten).

--

Leon

[Kevin Fenzi]

On Tue, May 16, 2023 at 11:05:26AM +0200, Leon Fauster via epel-devel wrote:
>  Am 15.05.23 um 20:50 schrieb Jonathan Wright:
>  > EPEL tracks RHEL, not clones.
>  > 
>  > EPEL10 is likely to resolve this, however.  Ref
>  > https://discussion.fedoraproject.org/t/epel-10-proposal
>  > <https://discussion.fedoraproject.org/t/epel-10-proposal>
>  > 
>  > On Mon, May 15, 2023 at 1:31 PM Leon Fauster via epel-devel
>  ...
>  > 
>  > 
>  >     While setting up a new workstation with an EL rebuild, I run into the
>  >     situation that ansible is not installable (rocky still on 9.1). Is there
>  >     a chance from EPEL side to close this time gap by at least keep older
>  >     packages (current-1) on the repos? Like epel-next closes the
> "forward"
>  >     gap, this would close such "backward" gap, thought ...
>  > 
>  >     --
>  >     Leon
>  
>  
>  Well, my point was not a strategy change, more a technical variation
>  that eliminates a lot of cases (also the above mentioned). Without
>  a single downgrade path, regressions can not be addressed. Just an
>  example: https://bugzilla.redhat.com/show_bug.cgi?id=2184351
>  
>  So, it was a general feasibility request. For those that slip into
>  such situation; there are still the repo archives, that get a copy
>  when a minor release happens (this one I had forgotten). 
This has been asked for many times, but our compose tooling doesn't lend
itself to doing this. :(

kevin