On Wed, Oct 20, 2021 at 8:52 AM Nico Kadel-Garcia <nka...@gmail.com> wrote:
>
> On Wed, Oct 20, 2021 at 2:24 AM Zbigniew Jędrzejewski-Szmek
> <zbys...@in.waw.pl> 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@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
