It's not possible to determine the difference between a non-keg-only
keg that failed to link and one that wasn't linked by us intentionally.
To avoid additional complexity of storing this logic in another place
let's back out this relatively new functionality; sticky keg-only links
is a better and more desirable behaviour anyway.
Treat a `brew install` command as normal i.e. link by default unless
keg-only and only specify whether a keg should be linked when upgrading
or reinstalling. Also, adjust the naming accordingly so it's more
obvious that this is the case.
This means if a user has manually `brew unlink` or `brew link --force`d
something then that status will be preserved after they `brew upgrade`
or `brew reinstall` that formula.
This generally should make things that are keg-only by default easier
to swallow.
Previously if a `brew reinstall` was Ctrl-Cd after some files had been
installed it wouldn't try to remove the partially installed keg and the
renaming of the backed-up keg would fail. Alternatively, remove the
partially installed keg as if it has been Ctrl-Cd or otherwise failed
then it's not desirable to keep it.
This is the same that happens in the command 'install'. By passing
the invalid option names, we enable the formula installer to output
warnings if necessary.
If `--with-foo` is provided to a formula through a tab or through
another formula depending on it and this option does not exist it
should be filtered. If it is not (the prior behaviour) then this can
prevent bottles being used unnecessarily.
Fixes#1399.
Since we are loading options as Formula#build from tab, we will have to explicitly read
options from ARGV as well.
Fixes#3066.
Closes#537.
Signed-off-by: Xu Cheng <xucheng@me.com>
add guard in Formula#file_modified? to prevent git popup
add guard in Superenv.bin before calling MacOS::Xcode.version
add guard against missing Xcode/CLT in Xcode.uncached_version
return nil instread of 0 in uncached_version when Xcode/CLT are not present, to distinguish from linuxbrew behavior
checks against pour_bottle? and needs_relocation?, add guard around keg.relocate_install_names to check pour_bottle?/needs_relocation? as well
needs_relocation? becomes skip_relocation?, use cellar attr to indicate relocation instead of does_not_need_relocation
MacOS.can_build? becomes MacOS.has_apple_developer_tools?
Add these new errors, and guards in formula installation and
cmd/{,un,re}install to match, move can_build? to the MacOS module,
flatten conditions, remove redundant can_build? check
reinstate removed (doctor) check
When running brew -v install, long post_install output from the formula,
presumably from upstream, may hide the important instructions in the
caveats and confuse the user. For example, postgresql runs initdb which
prints its own instructions for running the database, making the caveats
scroll off screen.
Per xu-cheng's instructions in Homebrew/homebrew#42565 :
Remove the explicit call to caveats from the install, reinstall, and
upgrade commands, as well as the dependency installer code in
FormulaInstaller#install_dependency , and call caveats right before the
summary code in FormulaInstaller#finish .
ClosesHomebrew/homebrew#42565.
Signed-off-by: Xu Cheng <xucheng@me.com>
In the case where a bottle wasn't around before and is now it probably
doesn't make sense to use `build-bottle` to build something that will
be identical to the binary bottle package anyway. After all, when you
use the bottle you will end up with something that has been built with
`build-bottle` anyway (just not by you).
Symlinks in opt and LinkedKegs point directly at a keg in the cellar, so
only resolving one symlink should suffice, and make it clear what path
we are actually interested in.
* Aborting during reinstall will now restore the originally installed
keg.
- Change install code to pass on CannotInstallFormulaError exception
to caller so it can be reused in reinstall.
* Add "--force-new-install" flag to force installing a new formula.
ClosesHomebrew/homebrew#22190.
Signed-off-by: Samuel John <github@SamuelJohn.de>
... and not just installed ones. Of course, strictly speaking,
reinstalling not-yet-installed formulae makes semantically little
sense, but the big win is that we can tell people (after we have
resolved an issue) to `brew reinstall <formula>` and even if a user
has removed that formula in the meantime, reinstall will do the right
thing. Basically adding --force to uninstall. I think this makes
reinstall more robust.
... and not just installed ones. Of course, strictly speaking,
reinstalling not-yet-installed formulae makes semantically little
sense, but the big win is that we can tell people (after we have
resolved an issue) to `brew reinstall <formula>` and even if a user
has removed that formula in the meantime, reinstall will do the right
thing. Basically adding --force to uninstall. I think this makes
reinstall more robust.
