Multiple README.md and LICENSE.md files from 140 modules breaks RPM building #348
Comments
|
I'm not sure whether we can modify collection content (from a legal point of view). Someone would have to clear that with RedHat legal. (CC @dmsimard @gundalow) Please note that some collections also have README.md files in other directories (in particular if they contain roles), so simply prepending them with collection names isn't enough. Maybe it's also worth filing a bug with rpmbuild, if it doesn't allow to work around this? |
|
I don't have a solution for this (yet) but I do want to point out we are also wondering about this in fedora packaging land: https://src.fedoraproject.org/rpms/ansible/pull-request/19#comment-90841 |
|
On Thu, Dec 2, 2021 at 4:27 PM Felix Fontein ***@***.***> wrote:
I'm not sure whether we can modify collection content (from a legal point
of view). Someone would have to clear that with RedHat legal. (CC
@dmsimard <https://github.com/dmsimard> @gundalow
<https://github.com/gundalow>)
Please note that some collections also have README.md files in other
directories (in particular if they contain roles), so simply prepending
them with collection names isn't enough.
Maybe it's also worth filing a bug with rpmbuild, if it doesn't allow to
work around this?
That would make sense, but take one heck of a lot longer: Revising rpmbuild
in production RHEL 8, which has the problem along with fedora. And yeah,
the extra README.md and README.rst files are.... a bit adventuresome. It's
one of the difficulties with presenting a monolithic tarball with so very
many third-party modules embedded in it. I admit that I prefer Fedora
rawhide's approach, up until now, of publishing the ansible_collection
modules individually rather than the very large tarball and all the
synchronization and integration issues it is causing.
|
|
I filed a bug report for rpm itself about this. The problem is simply not apparent with other software because they typically publish submodules as distinct RPMs built from distinct tarballs, as Fedora is effectively doing for ansible-collections modules. I'd also note that if you can't rename README.md or LICENSE.md files from the modules to something similar but unique, it's not open source or free software and does not belong in the published ansible tarball. |
I don't think the problem has anything to do with open source, but more with the fact that if you modify something, the legal situation changes, since you are no longer simply distributing a copy of the original, but a modified copy. I am not a lawyer so I can't tell you whether renaming something creates legal tripmines or not. |
If I may quote you, that is precisely the point of free software licenses and most open source licenses, that you are permitted to modify them. |
|
I have a pair of working .spec files, for 4.10.0 and 5.0.1. The full suite of needed python modules for ansible-core 2.11.7 and ansible core 2.12.0, and for ansibl-4.10. These work around the overlapping, path-stripped README.md and LICENSE files by pre-staging them with this kind of syntax, and staging licenses separately from docs. rsync -a --prune-empty-dirs ansible_collections/
I also included updated .spec files for ansible-core for RHEL 7 and RHEL 8.
I also lowered the ansible-core dependency for ansible-5.0.1, since it works with with ansible-core-2.11.7 on RHEL 7 and RHEL 8. |
I don't think you should call the resulting package "Ansible 5" then. Ansible 5 does have the modules/plugins contained in ansible-core 2.12, and ansible-core 2.11 does not have these. |
|
The resulting packages are called "ansible". The ansible-5.x-srpm directory
is merely a label to distinguish it from ansible-4.x-srpm, the spec file is
ansible.spec and the rpm is ansible.
The new ansible-4.0.10 and ansible-5.0.1 tarballs *do not* contain any of
the direct ansible python modules or the ansible binaries. I'm a bit sorry
to be a broken record about this. Since people keep cleaning that it does,
*test it*
pip3 install --no-deps --user ansible
Then try running the ansible binary, which will not exist in ~/.local/bin/,
and look in ~/.local/lib/python3.6/site-packages/ansible/ for the ansible
modules, which will not be there. The modules installed are all from
ansible galaxy, and all in ls
~/.local/lib/python3.6/site-packages/ansible_collections/, The idea that
the new ansible tarball contains the binaries as it did before, or the same
modules as ansible-core modules is not well founded.
Then run:
pip3 install ---user ansible-core
I won't criticize the renaming again, but please be aware that ansible 5.x
runs just fine with ansible-core 2.11.x: the requirement for ansible-core
2.12.0 is quite spurious and introduces an unwelcome dependency on python
3.8, one that is quite problematic for RHEL 7 and RHEL 8 packaging.
…On Wed, Dec 15, 2021 at 2:09 PM Felix Fontein ***@***.***> wrote:
I also lowered the ansible-core dependency for ansible-5.0.1, since it
works with with ansible-core-2.11.7 on RHEL 7 and RHEL 8.
I don't think you should call the resulting package "Ansible 5" then.
Ansible 5 does have the modules/plugins contained in ansible-core 2.12, and
ansible-core 2.11 does not have these.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#348 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKREG33A3S457POLYW23WLURDRW7ANCNFSM5JHOMXUQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
If you are installing |
|
You're right. That's because the ansible tarball is mislabeled and does not, in fact, contain the python modules or scripts for ansible itself. Ordinarily, I'd not be so concerned, but using my .spec files or using this works well.
Normally I'd not have made such a big deal, but if I'm publishing .spec files I want them to work as broadly as possible. There are compelling reasons that many .spec files use "BuildRequires" that have been manually altered from the "requirements.txt". |
|
The fix is present in my published .spec files, which I've updated to ansible 5.7.0. Using rsync to copy only the README and similar documentation files to the target document directory is efficient and easier to script. |
I've built up some tools to publish an "ansible" RPM with ansible-5.0.0. Unfortunately, the use of multiple README.md and LICENSE.md files from the variety of modules creates a problem: recent versions of "rpmbuild", such as those in RHEL 8 and in Fedora, try to copy those all as /usr/share/doc/ansible-5.0.0/README.md and /usr/share/doc/ansible-5.0.0/LICENSE.md.
I doubt I can rewrite or revise RPM to handle this better, this seems to be a new standard to reduce directory clutter under /usr/share/doc/ . How painful would it be to stuff a process in antsibull to preface the README.md and LICENSE.md filenames with the module name to avoid these conflicts?
The text was updated successfully, but these errors were encountered: