On Fri, Oct 15, 2021 at 11:39 PM Kevin Fenzi <kevin@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 <nkadel@gmail.com> wrote:
> > >
> > > On Fri, Oct 15, 2021 at 4:32 PM Ben Cotton <bcotton@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-leave@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