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 gotten a vaguely built RPM for it, for RHEL use, but I'm having some issues with the "pwsh" and other pecularities of "ansible-core" and it needs some work before I can install and test both. Backporting ansible-corre to my preferred working environments is more important for me than installing more than half a Gigabyte of modules I don't want, or need, to provide a few choice modules from the "ansible" package. Life also gets a bit weird with python2 still being /usr/bn/python on RHEL 7 based systems: that's a concern for EPEL. > 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. Why not? One github repo, one source tarball, one package. Ignore the pypi.org published tarball, it's way too big and clunky. Since I've seen previously that Fedora packaging standards are to follow pypi.org packaging.... OK. Use the tarball if needed. But yeah, the submodules are easily split in the .spec file. > 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?] Yeah, it would. > 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. And closer to the packaging of xorg, and Gnome, and KDE. > - it is still possible to have an 'ansible' metapackage that pulls in > those binary packages or some subset. Which is what I wish friends upstream had done in the *first* place with this monstrosity. The current tarball is like the old "Dagwood" sandwiches from the Blondie cartoon of my youth, it's just too big. > - the overhead is mostly about figuring out how to generated > descriptions and file lists for those 95 packages programatically. Yeah. I've generally been using pyp2rpm for generating fresh .spec files for pypi.org modules, A similar tools to pull modules, or sets of modules, from the galaxy collection is work I.... don't feel comfortable taking on today. > After that one-time cost it should be comparable to the overhead of > maintaining a giant binary package. > > Zbyszek Yeah. I don't myself want to be too free volunteering someone else's time to write this kind of packager. I'd be h appy to test it, especially if it can be RHEL 7 compatible. Maybe RHEL 8 compatible, if RHEL 7 is too far back to reach? There are a number of RPM macros I've found awkwardly missing when backporting this stuff. _______________________________________________ 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
