Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Wed, Oct 20, 2021 at 8:52 AM Nico Kadel-Garcia wrote: > > On Wed, Oct 20, 2021 at 2:24 AM Zbigniew Jędrzejewski-Szmek > 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 -, 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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
>> 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. > > Right: > > https://files.pythonhosted.org/packages/9b/ed/5a6149a7e0314bfb99fd496781f84a96328e0eb0a85f5cb845c25fcb909a/ansible-4.7.0.tar.gz > (36MB) > https://files.pythonhosted.org/packages/be/1a/f40e97f4c400eec75813bc492f1d6226cd413bf03f88d5f00070a1e699a3/ansible-core-2.11.6.tar.gz > (7MB) Another worthwhile datapoint might be the size of the ansible 2.9.x tarball which is still shipped with "batteries included" (though with less content than ships with >=4.x): https://files.pythonhosted.org/packages/5b/99/ce005d0314840e1a6eef34e0faf0ba4f7bccd8172b33cc84fee21afab7ad/ansible-2.9.27.tar.gz (14.8 MB) I must also point out that we are not satisfied with the size of the tarball either and that we have been trying to address it -- not just because of the size itself but because it has installation performance implications. Our attempts have been held back due to legal/licensing uncertainty around removing what we deem unnecessary files from the release tarballs and we are trying to do the right thing by clearing it through legal first. It takes time but we're in good faith actively trying to improve things, not make them worse. If you would like to stay up to date on that particular topic, you can subscribe to this issue: https://github.com/ansible-community/community-topics/issues/29 ___ 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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Wed, Oct 20, 2021 at 06:24:21AM +, Zbigniew Jędrzejewski-Szmek 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. ...snip... > > 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. Right: https://files.pythonhosted.org/packages/9b/ed/5a6149a7e0314bfb99fd496781f84a96328e0eb0a85f5cb845c25fcb909a/ansible-4.7.0.tar.gz (36MB) https://files.pythonhosted.org/packages/be/1a/f40e97f4c400eec75813bc492f1d6226cd413bf03f88d5f00070a1e699a3/ansible-core-2.11.6.tar.gz (7MB) > 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. Right. > 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?] Only if the seperately packaged collections are named differently, which is another level of confusion I don't think we want. ie, think if ansible 5.0 ships with ansible-collection-community-mysql version 2.3.1 and fedora has a seperately packaged ansible-collection-community-mysql 2.5.0. Users would get the updated version and not match the tested with ansible 5.0 version. > 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. It would need to pull in all those binary packages of exactly those versions in order to match upstream, but it couldn't where collections overlap seperately provided ones of different versions (unless named differently). kevin signature.asc Description: PGP signature ___ 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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Wed, Oct 20, 2021 at 2:24 AM Zbigniew Jędrzejewski-Szmek 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 -, 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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
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 -, 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@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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Tue, Oct 19, 2021 at 3:36 PM David Moreau-Simard wrote: > (replying from hyperkitty as I'm not subscribed to fedora-devel, hopefully > this works) > > > How about this: > > > > * Have a single ansible dist git repo with a single spec file > > * The source would be https://pypi.org/project/ansible/ > > There couldn't be a single source because 'ansible' and 'ansible-core' are > two distinct packages: > - https://pypi.org/project/ansible/ > - https://pypi.org/project/ansible-core/ > > Since >=2.10.x, 'ansible' is mostly composed of the ansible_collections > directory with a selection of included collections whereas 'ansible-core' > provides the CLI, runtime, builtin modules/plugins, etc. > > > * 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. > ok > The change that is currently proposed is somewhat of a middle ground to > unblock the situation and allow us to move forward: > - Users who aren't interested in the "batteries included" or "kitchen > sink" package can install ansible-core (note that ansible-core by itself > contains far less modules/plugins than ansible 2.9.x as those were split > out >=2.10.x) > Indeed - https://docs.ansible.com/ansible-core/2.11/collections/ansible/builtin/index.html (but note that this list doesn't include filters, or jinja2 built-ins) - Users of the 'ansible-core' package can install collections from Ansible > galaxy or from individually packaged collections > - Users of the 'ansible' package can install collections from Ansible > galaxy or from individually packaged collections and they will have > precedence over the ones installed by 'ansible' by default > - It doesn't prevent collections from being individually packaged if a > maintainer wants to do so > > Hopefully that makes sense and I'm happy to answer questions. > Yes, this makes sense. ___ > 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 > > ___ 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:
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
(replying from hyperkitty as I'm not subscribed to fedora-devel, hopefully this works) > How about this: > > * Have a single ansible dist git repo with a single spec file > * The source would be https://pypi.org/project/ansible/ There couldn't be a single source because 'ansible' and 'ansible-core' are two distinct packages: - https://pypi.org/project/ansible/ - https://pypi.org/project/ansible-core/ Since >=2.10.x, 'ansible' is mostly composed of the ansible_collections directory with a selection of included collections whereas 'ansible-core' provides the CLI, runtime, builtin modules/plugins, etc. > * 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 that is currently proposed is somewhat of a middle ground to unblock the situation and allow us to move forward: - Users who aren't interested in the "batteries included" or "kitchen sink" package can install ansible-core (note that ansible-core by itself contains far less modules/plugins than ansible 2.9.x as those were split out >=2.10.x) - Users of the 'ansible-core' package can install collections from Ansible galaxy or from individually packaged collections - Users of the 'ansible' package can install collections from Ansible galaxy or from individually packaged collections and they will have precedence over the ones installed by 'ansible' by default - It doesn't prevent collections from being individually packaged if a maintainer wants to do so Hopefully that makes sense and I'm happy to answer questions. ___ 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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 10:39 PM Nico Kadel-Garcia wrote: > On Sat, Oct 16, 2021 at 10:22 PM Kevin Fenzi 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 > > > 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@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 > ___ 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:
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 10:22 PM Kevin Fenzi 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. > > 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@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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
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). > 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... (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. > 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. Thanks. I appreciate the PR's... :) kevin signature.asc Description: PGP signature ___ 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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Fri, 2021-10-15 at 16:31 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Ansible5 > > == Summary == > > The ansible project has re-organized how they release and distribute > ansible. This change moves Fedora to be in sync with those changes > and > retires the old 'ansible classic/2.9.x' package in favor of a > 'ansible' package that pulls in ansible-core (the engine) and > includes > all the collections in upstream ansible releases. 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? 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). 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? 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. Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email signature.asc Description: This is a digitally signed message part ___ 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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
Hi Nico,
I understand your frustration about the Ansible reorganization, and I
agree that they could have documented it better, but I think that you
are missing the context surrounding this decision.
Oct 16, 2021 4:46:43 PM Nico Kadel-Garcia :
> On Sat, Oct 16, 2021 at 3:03 PM Gordon Messmer
> wrote:
> >
> > On 10/15/21 16:29, Nico Kadel-Garcia wrote:
> > >
> > > I would publish ansible-core as just that, with a "Provides:
> > > ansible
> > > %{version{-%{release}" and even "Obsoletes: ansible >=
> > > %{version}".
> > ...
> > > The "ansible" package could be a
> > > meta package with "Requires: ansible-core ansible_collections" to
> > > avoid the versioning confusion.
> >
> >
> > Those two things can't both be done, though, can they? If the
> > "ansible-core" package provides and obsoletes "ansible", then users
> > wouldn't be able to install the "ansible" package that requires
> > ansible_collections.
>
> They *can* physically, but doing both together would get very silly.
> I'd meant "do one or the other". The current model of "install
> ansible, get a few Megabytes of material you actually use that is
> almost entirely in ansible-core and 576 Megabytes of bulky material,
> more than 90% of which you will never use" is awkward, and I'd much
> rather see the galaxy collection packages published, and remain,
> distinct.
>
Fedora is not deprecating the current ansible-collection-* packages. If
you don't like the PyPi `ansible` package, then install the `ansible-
core` package and install the collections you want using the ansible-
collection-* Fedora packages or with `ansible-galaxy collection
install`, as the change description explains and Kevin reiterated.
> Discard the "ansible" package as an unwelcome approach, it's
> too big and too confusing.
I recommend you reread the initial post; it provides a good explanation
for why Ansible split most of the modules away from the core engine and
how the new packages (ansible-core and ansible) compare to the old
package (ansible 2.9). The new `ansible` package just contains the
collections that themselves contain the modules that, prior to Ansible
2.9, were hosted at github.com/ansible/ansible. The reason Ansible
created this new package was to avoid breaking existing workflows that
relied on those modules. Now, users can choose between installing the
collections manually or installing the `ansible` bundle.
>
>
> It does make me wish I'd been on the IRC channels that came up with
> this bundling to walk through the concerns much earlier. In practical
> terms and the relationship between Red Hat sponsored software like
> Ansible, and Fedora development, I acknowledge that it may be too
> late to revise. But that "too late" is a political and social issue,
> not necessarily a technical one.
I don't think this decision has anything to do with Fedora and RedHat's
relationship. All Fedora is really doing with this change is updating
the `ansible` package to the latest version available on PyPI. If you
were already using the `ansible-core` package, you can continue using
that. Fedora is not making any significant changes to that package with
this change.
> > As a practical matter, I don't see any functional difference
> > between the
> > proposed change (publishing an ansible-core package, and an ansible
> > package that contains collections) and your suggested alternative
> > (publishing an ansible-core package, and an ansible package that
> > requires collections), unless we disregard the meta package.
>
> It distinguishes the newly bundled ansible-core, which OK, that made
> sense to fragment, from an extremely bulky and therefore brittle
> bundle that is mostly unwelcome, even dangerous.
I don't think the `ansible` bundle is dangerous or unwelcome. The new
bundle is very helpful for people who don't want to deal with separate
dependencies and want to continue using Ansible as it used to be --
where all of the modules are included in one monolithic package.
Thanks,
Maxwell
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8
gotmax@e.email
signature.asc
Description: This is a digitally signed message part
___
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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
Hi, On Sat, 2021-10-16 at 15:33 -0700, Kevin Fenzi wrote: > On Sat, Oct 16, 2021 at 10:02:38AM -0400, Nico Kadel-Garcia wrote: > > > > it could have made good sense, and still would, for the "ansible" > > package to be what is now being colloquially referred to as > > "ansible-core", but for which the published upstream git repo is > > still > > https://github.com/ansible/ansible, and which is and will remain > > accessible as a github release tarball with the old numbering. The > > pypi.org published "ansible-core" is a republication of that repo > > with > > a new name duck-taped on it. Fragmenting out the bulky and > > potentially > > dynamic set of tools that are now in the "galaxy collections" suite > > makes some sense, but the result is that to get any of the core > > modules like "ansible.posix" we wind up including 573 Megabytes of > > unneeded and unwelcome debris in > > /usr/lib/python3.6/site-packages/ansible_collections. Very few of us > > need more than 10% of the list > > If you don't need more, don't install 'ansible'. Just install > ansible-core and use galaxy or seperate packaged collections to install > just what you need. > > > There is no specific source repository for the "ansible_collections" > > tarball, as best I can tell. The list of modules selected from the > > galaxy collection is very large, but incomplete and I've not seen any > > criteria for what goes in that tarball and what does not. Have you > > seen any? > > Yes, but I can't seem to find it now. ;( > Basically it was agreeing to use symantic versioning and agreeing to > release on the same schedule as the rest, etc. I don't know if there's > further requirements now. I'll find that doc and post it, but kinda > weekending now. ;) > > ...snip... > > kevin Here[1] is a link to the rules that collections must follow in order to be included in the `ansible` bundle. Here[2] is a link to the build data repository for the `ansible` package. This includes which versions of the collections exist in each version of the `ansible` package, as well as which versions of `ansible-core` each `ansible` package depends on. The Ansible team uses antsibull[3] to compile these releases. Thanks, Maxwell [1]: https://github.com/ansible-collections/ansible-inclusion [2]: https://github.com/ansible-community/ansible-build-data [3]: https://github.com/ansible-community/antsibull -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email signature.asc Description: This is a digitally signed message part ___ 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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 10:02:38AM -0400, Nico Kadel-Garcia wrote: > > it could have made good sense, and still would, for the "ansible" > package to be what is now being colloquially referred to as > "ansible-core", but for which the published upstream git repo is still > https://github.com/ansible/ansible, and which is and will remain > accessible as a github release tarball with the old numbering. The > pypi.org published "ansible-core" is a republication of that repo with > a new name duck-taped on it. Fragmenting out the bulky and potentially > dynamic set of tools that are now in the "galaxy collections" suite > makes some sense, but the result is that to get any of the core > modules like "ansible.posix" we wind up including 573 Megabytes of > unneeded and unwelcome debris in > /usr/lib/python3.6/site-packages/ansible_collections. Very few of us > need more than 10% of the list If you don't need more, don't install 'ansible'. Just install ansible-core and use galaxy or seperate packaged collections to install just what you need. > There is no specific source repository for the "ansible_collections" > tarball, as best I can tell. The list of modules selected from the > galaxy collection is very large, but incomplete and I've not seen any > criteria for what goes in that tarball and what does not. Have you > seen any? Yes, but I can't seem to find it now. ;( Basically it was agreeing to use symantic versioning and agreeing to release on the same schedule as the rest, etc. I don't know if there's further requirements now. I'll find that doc and post it, but kinda weekending now. ;) ...snip... kevin signature.asc Description: PGP signature ___ 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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 05:45:47PM -0400, Nico Kadel-Garcia wrote: > > They *can* physically, but doing both together would get very silly. > I'd meant "do one or the other". The current model of "install > ansible, get a few Megabytes of material you actually use that is > almost entirely in ansible-core and 576 Megabytes of bulky material, > more than 90% of which you will never use" is awkward, and I'd much > rather see the galaxy collection packages published, and remain, > distinct. Discard the "ansible" package as an unwelcome approach, it's > too big and too confusing. Then don't install it? For others it's comforting and welcome. "Hey, I can install all this stuff and it will be available if I want to use it, great!" ...snip... > What, then, about the existing > ansible-collection-ansible-netcommon-2.2.0-1.fc35.src.rpm and the > like? Would those be swept up as part of the "ansible" package? I'd no. > dislike that, and if we or the current maintainers can keep them > separate, it presrves the groundwork for a much more modular and much, > much smaller ansible deployment. collections can be packaged seperately. If you install 'ansible' and some seperate collections thats just fine. The seperate collections will be the version that gets used. So you can even up/downgrade from the version in 'ansible' if you want. If you want to install ansible-core and seperate specific collections you need, great, do that. ...snip... kevin signature.asc Description: PGP signature ___ 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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 3:03 PM Gordon Messmer wrote:
>
> On 10/15/21 16:29, Nico Kadel-Garcia wrote:
> >
> > I would publish ansible-core as just that, with a "Provides: ansible
> > %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
> ...
> > The "ansible" package could be a
> > meta package with "Requires: ansible-core ansible_collections" to
> > avoid the versioning confusion.
>
>
> Those two things can't both be done, though, can they? If the
> "ansible-core" package provides and obsoletes "ansible", then users
> wouldn't be able to install the "ansible" package that requires
> ansible_collections.
They *can* physically, but doing both together would get very silly.
I'd meant "do one or the other". The current model of "install
ansible, get a few Megabytes of material you actually use that is
almost entirely in ansible-core and 576 Megabytes of bulky material,
more than 90% of which you will never use" is awkward, and I'd much
rather see the galaxy collection packages published, and remain,
distinct. Discard the "ansible" package as an unwelcome approach, it's
too big and too confusing.
It does make me wish I'd been on the IRC channels that came up with
this bundling to walk through the concerns much earlier. In practical
terms and the relationship between Red Hat sponsored software like
Ansible, and Fedora development, I acknowledge that it may be too
late to revise. But that "too late" is a political and social issue,
not necessarily a technical one.
> As a practical matter, I don't see any functional difference between the
> proposed change (publishing an ansible-core package, and an ansible
> package that contains collections) and your suggested alternative
> (publishing an ansible-core package, and an ansible package that
> requires collections), unless we disregard the meta package.
It distinguishes the newly bundled ansible-core, which OK, that made
sense to fragment, from an extremely bulky and therefore brittle
bundle that is mostly unwelcome, even dangerous.
> Publishing an ansible-core package that provides "ansible" (or more
> specifically python3.Xdist(ansible)) wouldn't be compatible with the
> updated Python packaging policy, which requires PyPI parity.
If that's the locked in policy, and no exceptions. then I'd agree that
we as Fedora and as RHEL users are stuck with following PyPi and
ansible off the cliff in this case.
What, then, about the existing
ansible-collection-ansible-netcommon-2.2.0-1.fc35.src.rpm and the
like? Would those be swept up as part of the "ansible" package? I'd
dislike that, and if we or the current maintainers can keep them
separate, it presrves the groundwork for a much more modular and much,
much smaller ansible deployment.
> Anything
> that provides python3.Xdist(ansible) needs to provide at least a
> complete compatible interface with the package from PyPI, and an
> "ansible-core" package wouldn't.
That is a potential problem. Upstream broke it with the renumbering
without generating a distinct package. I don't think anyone or
anything will "Requires:" the new ansible package in RPM except as a
legacy entry for software that really relies on python components in
"ansible-core". I think they'll specifically need to import from
'ansible_collections' to get those individual python modules. It's
very messy.
There were a stack of options when ansible split up. Fedora is going
to have to deal with this peculiar layout one way or another. For
anyone who packages the new pypi "ansible" modules, I've some notes,
such as "rename the files with whitespace in their names", "Exchange
'#!/usr/bin/python' for '#!/usr/bin/python3'" and "#!/usr/bin/python'
for '#!/usr/bin/python3' for better cross-platform behavior, and
beware excessively long '%doc' and '%license' files with hundreds of
quite long entries.
> ___
> 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
___
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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On 10/15/21 16:29, Nico Kadel-Garcia wrote:
I would publish ansible-core as just that, with a "Provides: ansible
%{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
...
The "ansible" package could be a
meta package with "Requires: ansible-core ansible_collections" to
avoid the versioning confusion.
Those two things can't both be done, though, can they? If the
"ansible-core" package provides and obsoletes "ansible", then users
wouldn't be able to install the "ansible" package that requires
ansible_collections.
As a practical matter, I don't see any functional difference between the
proposed change (publishing an ansible-core package, and an ansible
package that contains collections) and your suggested alternative
(publishing an ansible-core package, and an ansible package that
requires collections), unless we disregard the meta package.
Publishing an ansible-core package that provides "ansible" (or more
specifically python3.Xdist(ansible)) wouldn't be compatible with the
updated Python packaging policy, which requires PyPI parity. Anything
that provides python3.Xdist(ansible) needs to provide at least a
complete compatible interface with the package from PyPI, and an
"ansible-core" package wouldn't.
___
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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Sat, Oct 16, 2021 at 8:04 AM Nico Kadel-Garcia wrote:
> On Fri, Oct 15, 2021 at 11:39 PM Kevin Fenzi wrote:
> >
> > On Fri, Oct 15, 2021 at 07:44:12PM -0400, Nico Kadel-Garcia wrote:
> > > On Fri, Oct 15, 2021 at 7:29 PM Nico Kadel-Garcia
> wrote:
> > > >
> > > > On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton
> wrote:
> > > > >
> > > > > https://fedoraproject.org/wiki/Changes/Ansible5
> > > > >
> > > > > == Summary ==
> > > > >
> > > > > The ansible project has re-organized how they release and
> distribute
> > > > > ansible. This change moves Fedora to be in sync with those changes
> and
> > > > > retires the old 'ansible classic/2.9.x' package in favor of a
> > > > > 'ansible' package that pulls in ansible-core (the engine) and
> includes
> > > > > all the collections in upstream ansible releases.
> > > >
> > > > I wrote to the various upstream bugtrackers about this already. The
> > > > re-org upstream is confusing and unwelcome, and creates a stack of
> > > > problems.
> >
> > Yeah, it's been confusing to people for sure, but it does also help out
> > a lot with other problems. :(
>
> it could have made good sense, and still would, for the "ansible"
> package to be what is now being colloquially referred to as
> "ansible-core", but for which the published upstream git repo is still
> https://github.com/ansible/ansible, and which is and will remain
> accessible as a github release tarball with the old numbering. The
> pypi.org published "ansible-core" is a republication of that repo with
> a new name duck-taped on it. Fragmenting out the bulky and potentially
> dynamic set of tools that are now in the "galaxy collections" suite
> makes some sense, but the result is that to get any of the core
> modules like "ansible.posix" we wind up including 573 Megabytes of
> unneeded and unwelcome debris in
> /usr/lib/python3.6/site-packages/ansible_collections. Very few of us
> need more than 10% of the list
>
> There is no specific source repository for the "ansible_collections"
> tarball, as best I can tell. The list of modules selected from the
> galaxy collection is very large, but incomplete and I've not seen any
> criteria for what goes in that tarball and what does not. Have you
> seen any?
>
> I'd suggest that discarding the pypi.org renaming and instead using
> the raw tarballs from github as sources for individual galaxy
> collection modules helps resolve. This would keep the numbering of the
> "ansible" RPM consistent, and its core functionality. The modules
> which have been shifted to the galaxy collection, such as the "ec2"
> and "cisco" modules, could and should be bundled individually as
> Fedora has been doing quite effectively. I did some tests: an RPM of
> the current pypi.org tarball mislabeled as "ansible" occupies more
> than 570 MBytes of local disk. If you want a lightweight Ansible
> setup, say for applying some playbooks to your localhost, it's an
> unreasonable burden.
>
Why not have both?
* In my experience and anecdotally, most Ansible users want to do a `dnf
install ansible` and get the entire 570 MB worth of plugins. Therefore, it
makes sense for Fedora to provide such an RPM named `ansible`. And this is
what other distributions are doing.
* But as you point out, there are many use cases (small device, edge, low
bandwidth, low disk space) where having an `ansible-core` package + the
ability to install just the needed collections is preferable.
I think the `ansible-core` package should not `Provides: ansible` because
ansible-core is most definitely not the historical `ansible` package. It
is misleading at best, dangerous at worst.
> Those numbers do not include the documentation: The sphinx build of
> the HTML docs is something I've tried, but so far is not working with
> my test SRPM. As it is, I've had to rename doc or license files that
> have " " in the filename because the '%doc' and '%license' macros do
> not like whitespace in filenames, and split them up because a
> '%license' or '%doc' that have so many hundreds of entries overwhelms
> SRPM scripting. Packaging up the individual modules or sets of modules
> individually avoids this unwelcome burden.
>
> > > > I would publish ansible-core as just that, with a "Provides: ansible
> > > > %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
> >
> > That would radically diverge from upstream and cause _more_ confusion.
>
> Upstream already confused people. I don't think it justifies repeating
> their bundling mistakes, mistakes that are not reflected in the
> upstream source code for the software but only in intermediate
> repackaging and which Fedora has so far effectively avoided.
> ___
> 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:
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Fri, Oct 15, 2021 at 11:39 PM Kevin Fenzi wrote:
>
> On Fri, Oct 15, 2021 at 07:44:12PM -0400, Nico Kadel-Garcia wrote:
> > On Fri, Oct 15, 2021 at 7:29 PM Nico Kadel-Garcia wrote:
> > >
> > > On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton wrote:
> > > >
> > > > https://fedoraproject.org/wiki/Changes/Ansible5
> > > >
> > > > == Summary ==
> > > >
> > > > The ansible project has re-organized how they release and distribute
> > > > ansible. This change moves Fedora to be in sync with those changes and
> > > > retires the old 'ansible classic/2.9.x' package in favor of a
> > > > 'ansible' package that pulls in ansible-core (the engine) and includes
> > > > all the collections in upstream ansible releases.
> > >
> > > I wrote to the various upstream bugtrackers about this already. The
> > > re-org upstream is confusing and unwelcome, and creates a stack of
> > > problems.
>
> Yeah, it's been confusing to people for sure, but it does also help out
> a lot with other problems. :(
it could have made good sense, and still would, for the "ansible"
package to be what is now being colloquially referred to as
"ansible-core", but for which the published upstream git repo is still
https://github.com/ansible/ansible, and which is and will remain
accessible as a github release tarball with the old numbering. The
pypi.org published "ansible-core" is a republication of that repo with
a new name duck-taped on it. Fragmenting out the bulky and potentially
dynamic set of tools that are now in the "galaxy collections" suite
makes some sense, but the result is that to get any of the core
modules like "ansible.posix" we wind up including 573 Megabytes of
unneeded and unwelcome debris in
/usr/lib/python3.6/site-packages/ansible_collections. Very few of us
need more than 10% of the list
There is no specific source repository for the "ansible_collections"
tarball, as best I can tell. The list of modules selected from the
galaxy collection is very large, but incomplete and I've not seen any
criteria for what goes in that tarball and what does not. Have you
seen any?
I'd suggest that discarding the pypi.org renaming and instead using
the raw tarballs from github as sources for individual galaxy
collection modules helps resolve. This would keep the numbering of the
"ansible" RPM consistent, and its core functionality. The modules
which have been shifted to the galaxy collection, such as the "ec2"
and "cisco" modules, could and should be bundled individually as
Fedora has been doing quite effectively. I did some tests: an RPM of
the current pypi.org tarball mislabeled as "ansible" occupies more
than 570 MBytes of local disk. If you want a lightweight Ansible
setup, say for applying some playbooks to your localhost, it's an
unreasonable burden.
Those numbers do not include the documentation: The sphinx build of
the HTML docs is something I've tried, but so far is not working with
my test SRPM. As it is, I've had to rename doc or license files that
have " " in the filename because the '%doc' and '%license' macros do
not like whitespace in filenames, and split them up because a
'%license' or '%doc' that have so many hundreds of entries overwhelms
SRPM scripting. Packaging up the individual modules or sets of modules
individually avoids this unwelcome burden.
> > > I would publish ansible-core as just that, with a "Provides: ansible
> > > %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
>
> That would radically diverge from upstream and cause _more_ confusion.
Upstream already confused people. I don't think it justifies repeating
their bundling mistakes, mistakes that are not reflected in the
upstream source code for the software but only in intermediate
repackaging and which Fedora has so far effectively avoided.
___
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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Fri, Oct 15, 2021 at 07:44:12PM -0400, Nico Kadel-Garcia wrote:
> On Fri, Oct 15, 2021 at 7:29 PM Nico Kadel-Garcia wrote:
> >
> > On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/Ansible5
> > >
> > > == Summary ==
> > >
> > > The ansible project has re-organized how they release and distribute
> > > ansible. This change moves Fedora to be in sync with those changes and
> > > retires the old 'ansible classic/2.9.x' package in favor of a
> > > 'ansible' package that pulls in ansible-core (the engine) and includes
> > > all the collections in upstream ansible releases.
> >
> > I wrote to the various upstream bugtrackers about this already. The
> > re-org upstream is confusing and unwelcome, and creates a stack of
> > problems.
Yeah, it's been confusing to people for sure, but it does also help out
a lot with other problems. :(
> > I would publish ansible-core as just that, with a "Provides: ansible
> > %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
That would radically diverge from upstream and cause _more_ confusion.
It's unfortunate that the 'ansible' name meaning has changed, but
ignoring it or overriding the upstream name isn't going to help matters.
> > The new pypi.org tarball published as "ansible" isn't. It's a tarball
> > of components from the Ansible galaxy collection, and it is
> > unnecessary for the basic ansible-core operation, which are much
> > bulkier than the previous "ansible" and contains approximately 145
> > distinct software licenses. That is a sign of a packaging problem
> > that I've discussed on the pypi.org issues pages, at
>
> I realize I was unclear. The new "ansible" tarball from pypi.org has
> 145 distinct software licenses, and many distinct galaxy collection
> published ansible modules. The new "ansible-core" tarball is much
> smaller, even smaller than the old "ansible" package due to some bulky
> modules being transferred to the galaxy collection.
Right.
> Splitting off the variety of add-on modules makes sense. Replacing the
> core package with the add-on modules and moving aside the core seems
> exactly backwards.
Well, I think the thought was that people would find ansible-core too
bare bones after having used ansible-2.9/classic with all it's included
modules.
If you don't want the collections, just install ansible-core.
kevin
signature.asc
Description: PGP signature
___
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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Fri, Oct 15, 2021 at 7:29 PM Nico Kadel-Garcia wrote:
>
> On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Ansible5
> >
> > == Summary ==
> >
> > The ansible project has re-organized how they release and distribute
> > ansible. This change moves Fedora to be in sync with those changes and
> > retires the old 'ansible classic/2.9.x' package in favor of a
> > 'ansible' package that pulls in ansible-core (the engine) and includes
> > all the collections in upstream ansible releases.
>
> I wrote to the various upstream bugtrackers about this already. The
> re-org upstream is confusing and unwelcome, and creates a stack of
> problems.
>
> I would publish ansible-core as just that, with a "Provides: ansible
> %{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
> The new pypi.org tarball published as "ansible" isn't. It's a tarball
> of components from the Ansible galaxy collection, and it is
> unnecessary for the basic ansible-core operation, which are much
> bulkier than the previous "ansible" and contains approximately 145
> distinct software licenses. That is a sign of a packaging problem
> that I've discussed on the pypi.org issues pages, at
I realize I was unclear. The new "ansible" tarball from pypi.org has
145 distinct software licenses, and many distinct galaxy collection
published ansible modules. The new "ansible-core" tarball is much
smaller, even smaller than the old "ansible" package due to some bulky
modules being transferred to the galaxy collection.
Splitting off the variety of add-on modules makes sense. Replacing the
core package with the add-on modules and moving aside the core seems
exactly backwards.
___
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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/Ansible5
>
> == Summary ==
>
> The ansible project has re-organized how they release and distribute
> ansible. This change moves Fedora to be in sync with those changes and
> retires the old 'ansible classic/2.9.x' package in favor of a
> 'ansible' package that pulls in ansible-core (the engine) and includes
> all the collections in upstream ansible releases.
I wrote to the various upstream bugtrackers about this already. The
re-org upstream is confusing and unwelcome, and creates a stack of
problems.
I would publish ansible-core as just that, with a "Provides: ansible
%{version{-%{release}" and even "Obsoletes: ansible >= %{version}".
The new pypi.org tarball published as "ansible" isn't. It's a tarball
of components from the Ansible galaxy collection, and it is
unnecessary for the basic ansible-core operation, which are much
bulkier than the previous "ansible" and contains approximately 145
distinct software licenses. That is a sign of a packaging problem
that I've discussed on the pypi.org issues pages, at
The new "ansible" labeled pypi.org module has no full provenance I've
been able to find. It assembles a number of distinct galaxy collection
published re[ps from https://github.com/orgs/ansible-community/, but
assembled without any reference tool that I can find or detect any
documentation for. I'd say that this is messy and not ready for
bundling, and hope that its authors can clean this up.
Given choices I'd publish the "ansible_collections" tarball as just
such an RPM, since it is installed in
/usr/lib/python3.[subversion]/site-packages/ansible_collections/ and
should have been labeled that way. The "ansible" package could be a
meta package with "Requires: ansible-core ansible_collections" to
avoid the versioning confusion.
___
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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
The subject is wrong. This Change proposal is for Fedora Linux *36*. Whoops! -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
