On Sat, Oct 16, 2021 at 8:04 AM Nico Kadel-Garcia <nka...@gmail.com> wrote:
> On Fri, Oct 15, 2021 at 11:39 PM Kevin Fenzi <ke...@scrye.com> 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 <nka...@gmail.com> > wrote: > > > > > > > > On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton <bcot...@redhat.com> > 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: 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
