On Tue, Oct 19, 2021 at 3:36 PM David Moreau-Simard <dmsim...@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/ansible.in > ) > - 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/ansible-5.0.0a2.deps > ) > - 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/index.html (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. _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
