2023-01-31T14:05:11Z David Moreau-Simard <moi(a)dmsimard.com>:
Hi,
Answer in-line but I also want to extend an invititation to everyone here
to join #ansible-packaging on libera.chat (or #packaging:ansible.com on
Matrix) which is a low signal-to-noise ratio channel to talk about
Ansible packaging things such as this one :)
------- Original Message -------
On Tuesday, January 31st, 2023 at 8:01 AM, Sagi Shnaidman
<sshnaidm(a)redhat.com> wrote:
Hi, Orion
Thanks for raising this question.
I use both ways - either ansible distro with all-inclusive, or ansible
(distro or "core") with specific collection installed separately when I
need a newer version of collection, for example. I wonder if it's
possible to continue to update collections to the newest versions
anyway. If someone wants to use the collection version provided in "big
ansible", they would use ansible 6.3.0 with all included. If they want
a newer collection, they can install a separate newest RPM.
But not sure if dependencies can be a problem here, like which
collection version depends on other collection versions (for example
ansible.utils, which is part of multiple collection dependencies).
We took this use case into account when we refacoted the Fedora ansible
package to match the "post ansible 2.9 era", see:
*
https://fedoraproject.org/wiki/Changes/Ansible5
*
https://src.fedoraproject.org/rpms/ansible/blob/rawhide/f/ansible.spec#_207
TL;DR:
* The ansible package installs collections to the python site-lib
* The ansible collections packages should (generally?) install to
/usr/share
* Installing manually from galaxy installs to ~/.ansible
The order of precedence makes it so galaxy-installed collections will
have priority over those installed by the collection packages which have
precedence over those installed by the ansible package.
There may be edge cases where mismatched dependencies could lead to
issues but I'm not sure we can do much about that.
> Let me know what you think.
>
> Thanks
>
> On Tue, Jan 31, 2023 at 2:14 PM Paul Howarth <paul(a)city-fan.org> wrote:
>> On Mon, 30 Jan 2023 21:13:11 -0700
>> Orion Poplawski <orion(a)nwra.com> wrote:
>>
>>> So, I'm wondering if we should have some kind of (at least
>>> semi-)coordinated plan for updating ansible collections in EPEL?
>>>
>>> My initial thought is we would sort of piggy back on to what the
>>> "ansible" community collection bundles on top of the ansible-core
>>> package provided by RedHat. So, currently in EL8.7 we have:
>>>
>>> ansible-core-2.13.3
>>>
>>> and EPEL ships:
>>>
>>> ansible-6.3.0 - which corresponds to the ansible community package
>>> that ships with ansible-2.13.3.
>>>
>>> Then we would endeavor to ship the individual package collection
>>> versions that are contained in that package, .e.g: (taken from the
>>> MANIFEST.json files):
>>>
>>> ansible.posix 1.4.0
>>> ansible.utils 2.6.1
>>> chocolatey.chocolatey 1.3.0
>>> community.docker 2.7.1
>>> community.general 5.5.0
>>> community.libvirt 1.2.0
>>> community.mysql 3.4.0
>>> community.rabbitmq 1.2.2
>>> containers.podman 1.9.4
>>> netbox.netbox 3.7.1
>>
>> Sounds like a reasonable plan to me.
>>
>>> For reference, currently in epel we have:
>> ...
>>> ansible-collection-community-libvirt.noarch 1.1.0-3.el8
>>> epel
>>
>> I updated ansible-collection-community-libvirt to 1.2.0:
>>
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-98b1fc46a5
>>
>>> I don't really have a particular agenda here, just trying to solicit
>>> people's thoughts. Personally I like minimal installs so I have been
>>> only using ansible-core + collections on the systems I maintain and
>>> would like to continue to see them be usable together.
>>
>> I too just use ansible-core + collections on the systems I maintain.
>>
>> Regards, Paul.
>>
>
>
> --
> Best regards
> Sagi Shnaidman