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/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. 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
