On Wed, Oct 20, 2021 at 8:52 AM Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: > > On Wed, Oct 20, 2021 at 2:24 AM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > > 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. > > There is no SRPM, because no one has successfully packaged it. There > is a very bulky upstream tarball, and it is peculiarly constructed. > and it is mislabeled because all of its contents except some > ansible.egg-info files wind up in > /usr/lib/python3.x/site-packages/ansible_collections/, and are > referred to in python based on that location and with the prefix name > "ansible_collections", not "ansible". I've published a .spec file for ansible-4.7.0, as much as I've protested the unwelcome mishandling of the ansible split. I've included RHEL 7, RHEL 8. and Fedora Core 34 compatible .spec files for ansible-core, ansible, and all the rawhide published ansible-collections are available at: https://github.com/nkadel/ansiblerepo/ I'm not currently an authorized Fedora packager, so anyone willing to take these on or accept them as updates is welcome to do so. There are testing issues: Testing all of the new "ansible" bundle is a nightmare because of its distinct 140 modules, many of which are for quite specific hardware management such s fortigate and cisco. This is another reason to strongly prefer the much smaller "ansibole-collecion-*" RPMs. The "ansible-collection-" packages are not installed under /usr/lib/python3[subversion]/site-packages/aws-collections/ but under /usr/share/ansible/, so they don't intermingle. The syntax of "Requires: ansible > 4.0 or ansible-core >= 2.9" used by some of the "ansible-collection" packages does not work in RHEL, only in recent fedora releases, and should be discarded in favor of 'Require: ansible-core >= 2.9' for consistently and compatibility. That means dumping the older "ansible" requirements, which will be functional with the new mislabeled and misnumbered "ansible" RPM, even though it will bring in over 500 Megabytes of unnecessary and mostly unwelcome modules. The hundreds of 'README.md' doc files, building the RPM under RHEL 8, wind up copied to exactly the same lucation under /user/share/doc/ becasue RHEL 8 apparently believes in stripping the subdirectories of individual README.md files, so the "ansible" documentation won't work. Since there is no master directory for the sphinx documentation, that is also going to take 145 or so distinct sphinx commands and assembly of all the resulting html subdirs. Since sphinx doesn't even work for ansible-core, and is one of the least reliable components of building python RPMs, I'm not going to even start trying to fix that. There are a stack of unlisted requirements not in the "requirements.txt" of the new ansible-4.7.0 tarball: BuildRequires: python%{python3_pkgversion}-cryptography BuildRequires: python%{python3_pkgversion}-resolvelib BuildRequires: python%{python3_pkgversion}-sphinx_rtd_theme _______________________________________________ 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
