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

RFE: Issue dependency loop warnings by default #2941

Open
pmatilai opened this issue Feb 29, 2024 · 2 comments
Open

RFE: Issue dependency loop warnings by default #2941

pmatilai opened this issue Feb 29, 2024 · 2 comments

Comments

@pmatilai
Copy link
Member

As distros keep growing and getting more complex, there's an ever increasing amount of dependency loops causing install failures without us giving any meaningful hints at what could be wrong. Rpm has "always" had a --deploops switch that can be enabled for diagnosing loops, but we should really emit that output by default. Small loops can usually be handled without problems so we probably shouldn't emit warnings on every single loop, but instead issue warnings over a configurable threshold. Based on what I've seen over the years, a loop with >= 100 members has no chance of getting correctly installed, whereas a loop with <= 10 are rarely problematic. The default threshold should be somewhere between those two...

@pmatilai
Copy link
Member Author

Another related thing we could easily do is track the SCC member status in the rpmte's themselves, and in case of a scriptlet failure, emit a special "this could be due to a dependency loop" type message for packages in a deploop.

@pmatilai
Copy link
Member Author

On a related note, we should really differentiate between loops which we can resolve, and those that we can't. Eg a loop which resolves reliably by eg pre/post qualifier, there's no reason to complain about, probably not even --deploops output. The ones we can't resolve, we should make far more visible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Priority
Development

No branches or pull requests

1 participant