On Sat, Oct 16, 2021 at 10:39 PM Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:
On Sat, Oct 16, 2021 at 10:22 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote:
>
> On Sat, Oct 16, 2021 at 08:51:46PM -0500, Maxwell G via devel wrote:
> >
> > Hi everyone,
> >
> > I have a couple comments/questions about this change.
> >
> > How will this effect EPEL? Is the plan to keep Ansible 2.9 there for
> > now?
>
> For now yes, but 2.9 will go EOL at the end of the year (last I heard).
I think someone is being very, very optimistic. It's especially tricky
because EPEL does not keep previously released versions of software in
their primary repos. If ansible the github tagged ansible 2.10,
rebundled as ansible-core
> > Could we also consider making Ansible a modular package on both Fedora
> > and EPEL? Then, it would be possible to install any of the currently
> > supported versions of the Ansible core/engine (ansible 2.9, ansible-
> > base 2.10, and ansible-core 2.11).
>
> No thanks. It would be a ton of effort, and those will all EOL soon
> or already have...
Don't count on it. The python 3.8 requirement for ansible-core 2.12
and ansible 5.0, as described at Installing Ansible — Ansible
Documentation is going to case difficulties porting it to RHEL
especially RHEL 7. There are no "python38" or "python310" packages
I've found for RHEL 7, except the SCLO packages which are awkward to
use. Many people have been very, very reluctant to update to RHEL 8
and CentOS 8 for various reasons, so I expect to see some demand for
ansible to roll back that pending required python update, or perhaps
EPEL to organize a python310 suite of python components.
> (from the ansible 4.7.0 release announcement:
>
> "* Except for ansible-2.9.x, older versions of ansible are no longer
> seeing maintenance releases."
>
> > Will the new `ansible` package have virtual provides for the
> > collections it provides? While there is not a good reason to, it will
> > still be possible to install both the new `ansible` package and any of
> > the ansible-collection-* packages, right?
>
> I don't think we will do provides, that would cause problems installing
> the stand alone collections. So, yeah, we want to be able to install the
> stand alone collections along with or in addition to the bundle.
I'd prefer "instead of". That might require a more complete set of
collection components, to avoid installing "ansible" and potentially
conflicting.
How about this:
* Have a single ansible dist git repo with a single spec file
* The source would be https://pypi.org/project/ansible/
* 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
* Have a single ansible dist git repo with a single spec file
* The source would be https://pypi.org/project/ansible/
* 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
> > Also, I would be happy to help with Ansible packaging in Fedora;
> > however, I am not yet part of the packager group and still need a
> > sponsor.
You'll also need a stiff drink. The process is slow because of the
size of the monolithic collection, and the cleanups needed to get all
the docs and licenses packaged.
> Thanks. I appreciate the PR's... :)
>
> kevin
_______________________________________________
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
_______________________________________________ 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
