On Sat, Oct 16, 2021 at 3:03 PM Gordon Messmer <gordon.messmer@xxxxxxxxx> 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@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
