On Tue, Oct 19, 2021 at 3:36 PM David Moreau-Simard <dmsimard(a)redhat.com>
wrote:
(replying from hyperkitty as I'm not subscribed to fedora-devel,
hopefully
this works)
> How about this:
>
> * Have a single ansible dist git repo with a single spec file
> * The source would be
https://pypi.org/project/ansible/
There couldn't be a single source because 'ansible' and
'ansible-core' are
two distinct packages:
-
https://pypi.org/project/ansible/
-
https://pypi.org/project/ansible-core/
Since >=2.10.x, 'ansible' is mostly composed of the ansible_collections
directory with a selection of included collections whereas 'ansible-core'
provides the CLI, runtime, builtin modules/plugins, etc.
> * Produce multiple RPM packages from this spec file
> * ansible-core
> * one RPM package for each collection in the pypi ansible package -
> these could be created programatically in the spec file using LUA or
other
> spec file automation to create separate package, documentation, files,
> Requires, etc. for each collection package
> * a package called "ansible" which is essentially a meta-package
which
> simply does a "Requires: ansible-core" and also "Requires"
every
> collection
> package
>
> That way, there is a single source for any/all combinations of
ansible-core
> + collection rpms, or the entire ansible containing everything.
>
> One downside is that this restricts the ability to produce fixes or
> upgrades for individual collections independently of the rest of the
> Ansible packages. But I think that's only a problem if
>
> * the independent collections change frequently
> * the
https://pypi.org/project/ansible lags behind and doesn't keep up
> with the collections
In fact, we first considered proposing something that was similar to what
you suggest -- an ansible package that pulls in individually packaged
collections as well as ansible-core - before settling on the change at
https://fedoraproject.org/wiki/Changes/Ansible5.
We concluded that it would be hard to do in practice because:
- Ansible 5 will ship with ~95 individual collections (
https://github.com/ansible-community/ansible-build-data/blob/main/5/ansib...
)
- Of these 95 collections, there's only about a dozen that are already
packaged (I wrote down some notes here:
https://hackmd.io/iAloYlTQQ3e-yi99w_o54A)
- The versions of individually packaged collections could diverge from
those shipped inside the 'ansible' package (ex:
https://github.com/ansible-community/ansible-build-data/blob/main/5/ansib...
)
- Even considering we develop tooling and automation around the process,
it would still be error prone and a lot of work without mentioning the
administrative overhead of maintaining 95+ packages
In short: it would require a non-negligible amount of effort to package
each individual collection, keep them updated while in sync with the
versions that the upstream package ships without conflicts.
ok
The change that is currently proposed is somewhat of a middle ground
to
unblock the situation and allow us to move forward:
- Users who aren't interested in the "batteries included" or "kitchen
sink" package can install ansible-core (note that ansible-core by itself
contains far less modules/plugins than ansible 2.9.x as those were split
out >=2.10.x)
Indeed -
https://docs.ansible.com/ansible-core/2.11/collections/ansible/builtin/in...
(but note that this list doesn't include filters, or jinja2 built-ins)
- Users of the 'ansible-core' package can install collections from Ansible
galaxy or from individually packaged collections
- Users of the 'ansible' package can install collections from Ansible
galaxy or from individually packaged collections and they will have
precedence over the ones installed by 'ansible' by default
- It doesn't prevent collections from being individually packaged if a
maintainer wants to do so
Hopefully that makes sense and I'm happy to answer questions.
Yes, this makes sense.
_______________________________________________