Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dealing with broken collection deps #493

Open
nitzmahone opened this issue Apr 25, 2023 · 2 comments · May be fixed by #664
Open

Dealing with broken collection deps #493

nitzmahone opened this issue Apr 25, 2023 · 2 comments · May be fixed by #664

Comments

@nitzmahone
Copy link
Member

There will be inevitable cases where a collection declares incorrect, conflicting, or just-plain-broken dependencies- as of builder 3.0rc1, there's no way to just ignore those deps to allow the EE build to continue.

We don't want to get into the business of transforming, constraining, or substituting build dependencies, but providing a per-collection mechanism for "I don't want to consider part of this collection's declared deps" seems like a useful (and sometimes necessary) escape hatch.

Since we're just passing through the Galaxy requirements.yml, the most obvious method (annotating the requirements inline) is probably a non-starter, as we'd have to filter and re-generate the inputs to Galaxy in that case. So we're left with declaring that somewhere else in the EE def.

Perhaps something like the following:

dependencies:
  galaxy: |
    collections:
    - ansible.utils
    - community.windows
options:
  dependency_control:
    - collection: ansible.utils
      ignore_bindep: true
      ignore_python: true

Could get fancier with the ability to mask individual requirements, ignore cross-collection dependencies, ignore all...

We'd take this information into account as we generate unified requirements files, dropping data from individual sources as requested. Global "never install this package" kinds of things probably aren't possible, but something like this would at least allow the installation of a broken collection version in conjunction with manual addition of the necessary deps.

@github-actions github-actions bot added the needs_triage New item that needs to be triaged label Apr 25, 2023
@sivel sivel removed the needs_triage New item that needs to be triaged label Jun 1, 2023
@laurent-indermuehle
Copy link

laurent-indermuehle commented Nov 24, 2023

I also think this is a necessary feature.
I failed to build a custom image based on registry.redhat.io/ansible-automation-platform-24/ee-supported-rhel9:latest because the included redhat.sso collection tries to install python39-devel RPM. But it doesn't exist.
I failed to build a custom image based on registry.redhat.io/ansible-automation-platform-24/ee-minimal-rhel8:latest (and rhel9, same issue) because the collection kubernetes.core tries to install openshift-clients RPM. But it doesn't exist.

And I don't need those collections... they are added automatically by ansible-builder :(
And I use ansible-builder on RHEL9.

@laurent-indermuehle
Copy link

Also, reading https://access.redhat.com/solutions/6990615 made me wonder if it won't be easier to just fix the dependencies error upstream in redhat.sso and kubernets.core.
The later is causing issues since months...

In the solution above, a user offered a radical solution:

RUN rm -rf /usr/share/ansible/collections/ansible_collections/kubernetes/
RUN rpm -e $(rpm -qa openshift-clients*)

@sivel sivel linked a pull request Mar 26, 2024 that will close this issue
5 tasks
@Shrews Shrews linked a pull request Apr 12, 2024 that will close this issue
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

3 participants