FWIW, I think the upstream renaming of ansible and ansible-core is something
that we just have to accept. But we have some flexibility in how this is
packaged in Fedora.
On Tue, Oct 19, 2021 at 09:34:34PM -0000, David Moreau-Simard wrote:
[> Richard Meggins wrote:]
> * 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.
The Change proposal is not very clear in this regard… Please correct me
if I'm wrong, but my understanding is that there's a giant SRPM which
produces a giant 'ansible' binary package. In addition there's a second
small SRPM which produces the 'ansible-core' binary package.
When I'm reading Richard's proposal, I understand it as a giant SRPM
package + ~95 binary packages. In your answer, you are clearly discussing
~95 SRPM packages with ~95 binary packages.
I agree that ~95 separate *source* packages is not a good approach:
- the obvious reason is the packaging overhead you mention
- but a more subtle reason is that upstream will test those 95 packages
in the versions listed in 'ansible' pypi package, so we want them in
the exact versions specified in the 'ansible' pypi package, and not
in the latest version each of those upstreams may have released.
But the approach with 1 SRPM and many *binary* packages seems pretty
attractive:
- it will be possible to install specific subset of the collection
as rpm packages. [Nico, does that answer you complaint about installation
size?]
To some extent this will match the split of *binary* packages of texlive.
is very useful when one knows the few specific subpackages that
one needs through the 'tex(foo.sty)' and 'tex(bar.tfm)' virtual
provides.
- it is still possible to have an 'ansible' metapackage that pulls in
those binary packages or some subset.
- the overhead is mostly about figuring out how to generated
descriptions and file lists for those 95 packages programatically.
After that one-time cost it should be comparable to the overhead of
maintaining a giant binary package.
Zbyszek