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

brew cleanup should continue even if it wasn't permitted to remove a file #11924

Closed
andreasabel opened this issue Aug 26, 2021 · 12 comments · Fixed by #11931
Closed

brew cleanup should continue even if it wasn't permitted to remove a file #11924

andreasabel opened this issue Aug 26, 2021 · 12 comments · Fixed by #11931
Labels
bug Reproducible Homebrew/brew bug outdated PR was locked due to age

Comments

@andreasabel
Copy link

Provide a detailed description of the proposed feature

Current situation:

$ brew cleanup --debug
...
Removing: /usr/local/Cellar/icu4c/67.1... (258 files, 71MB)
Error: Directory not empty @ dir_s_rmdir - /usr/local/Cellar/icu4c/67.1

/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1431:in `rmdir'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1431:in `block in remove_dir1'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1442:in `platform_support'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1430:in `remove_dir1'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1423:in `remove'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:760:in `block in remove_entry'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1480:in `ensure in postorder_traverse'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:1480:in `postorder_traverse'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:758:in `remove_entry'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:610:in `block in rm_r'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:606:in `each'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/fileutils.rb:606:in `rm_r'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.6.3_2/lib/ruby/2.6.0/pathname.rb:589:in `rmtree'
/usr/local/Homebrew/Library/Homebrew/keg.rb:275:in `uninstall'
/usr/local/Homebrew/Library/Homebrew/cleanup.rb:252:in `block in cleanup_keg'
/usr/local/Homebrew/Library/Homebrew/cleanup.rb:338:in `cleanup_path'
/usr/local/Homebrew/Library/Homebrew/cleanup.rb:252:in `cleanup_keg'
/usr/local/Homebrew/Library/Homebrew/cleanup.rb:238:in `each'
/usr/local/Homebrew/Library/Homebrew/cleanup.rb:238:in `cleanup_formula'
/usr/local/Homebrew/Library/Homebrew/cleanup.rb:190:in `block in clean!'
/usr/local/Homebrew/Library/Homebrew/cleanup.rb:189:in `each'
/usr/local/Homebrew/Library/Homebrew/cleanup.rb:189:in `clean!'
/usr/local/Homebrew/Library/Homebrew/cmd/cleanup.rb:58:in `cleanup'
/usr/local/Homebrew/Library/Homebrew/brew.rb:129:in `<main>'

Atm, brew cleanup crashes instead of continuing to clean up.

Feature suggestion: ignore errors, or at least if a flag like --ignore-errors, -i is given.

What is the motivation for the feature?

There might be dynlibs I want to hang on so that upgrades do not remove them. After all, other programs (outside of the brew universe) have been linked against than and brew cleanup breaks them mercilessly. A simple workaround is to forbid brew to remove this files by making them read-only, but then brew cleanup crashes.

How will the feature be relevant to at least 90% of Homebrew users?

I suppose only 10% use brew exclusively for everything.

What alternatives to the feature have been considered?

N/A

@andreasabel andreasabel added the features New features label Aug 26, 2021
@MikeMcQuaid MikeMcQuaid added bug Reproducible Homebrew/brew bug and removed features New features labels Aug 26, 2021
@MikeMcQuaid
Copy link
Member

Atm, brew cleanup crashes instead of continuing to clean up.

This is generally considered a bug rather than a feature. We try to catch the relevant exceptions and continue but this is imperfect.

There might be dynlibs I want to hang on so that upgrades do not remove them. After all, other programs (outside of the brew universe) have been linked against than and brew cleanup breaks them mercilessly. A simple workaround is to forbid brew to remove this files by making them read-only, but then brew cleanup crashes.

In this case, though, you should set HOMEBREW_NO_INSTALL_CLEANUP instead. It's expected that Homebrew trying to cleanup its own files failing because you've intentionally changed the permissions will error out.

@andreasabel
Copy link
Author

In this case, though, you should set HOMEBREW_NO_INSTALL_CLEANUP instead.

No, don't get me wrong. I do want cleanup, I just want to hang on to certain files that have been linked to other executable.

Atm, brew cleanup crashes instead of continuing to clean up.

This is generally considered a bug rather than a feature.

I agree. Should I report it as bug instead?

@carlocab
Copy link
Member

You can still pass a formula name to brew cleanup to clean up as specific formula. That's not exactly the behaviour that you want, but it's probably still better than trying to clean up the cellar manually.

That said, I do think allowing HOMEBREW_NO_INSTALL_CLEANUP to be set to a list of formulae you don't want to be cleaned up might be a nice feature. I don't have time to implement this, but I'd be happy to review a PR that does.

@MikeMcQuaid
Copy link
Member

I agree. Should I report it as bug instead?

No, I've relabelled it but consider this to be working as desired.

No, don't get me wrong. I do want cleanup, I just want to hang on to certain files that have been linked to other executable.

That's not cleanup, as far as we're concerned.

@andreasabel
Copy link
Author

andreasabel commented Aug 26, 2021

I see.

Is there a workaround, like registering packages to brew that should not be cleaned up?
Very concretely, I want to keep old versions of icu4c (libraries) around.

@carlocab
Copy link
Member

Is there a workaround, like registering packages to brew that should not be cleaned up?

Not currently. This is what my suggestion above would do:

That said, I do think allowing HOMEBREW_NO_INSTALL_CLEANUP to be set to a list of formulae you don't want to be cleaned up might be a nice feature

@MikeMcQuaid
Copy link
Member

@andreasabel brew pin icu4c may do what you want.

@andreasabel
Copy link
Author

@MikeMcQuaid: Thanks! This might last me a while, until some apps demand a newer version of icu4c.
A HOMEBREW_NO_CLEANUP=icu4c like in @carlocab's suggestion would take me all the way...

@carlocab
Copy link
Member

It turns out this wasn't too hard, and when you've got an itch... #11931

@carlocab
Copy link
Member

I've merged #11931. If you're on the brew master branch (e.g. if you're run a dev command -- see brew developer), then you should be able to do this with brew update. If not, you can wait until it lands on a release tag, or run brew developer on && brew update.

@andreasabel
Copy link
Author

@carlocab Wonderful, that's great! I tried HOMEBREW_NO_CLEANUP_FORMULAE=icu4c with brew cleanup on the developer version and it did what I had wanted for a long time!

@carlocab
Copy link
Member

carlocab commented Sep 7, 2021

HOMEBREW_NO_CLEANUP_FORMULAE is also in 3.2.11, so you don't need to be on the developer branch to use it.

Glad it's working for you.

@github-actions github-actions bot added the outdated PR was locked due to age label Oct 8, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Reproducible Homebrew/brew bug outdated PR was locked due to age
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants