Things that install Guile scheme objects should be doing so in
HOMEBREW_PREFIX/share/guile/site, which should be persistent rather
than a symlink to any formulae's Cellar, not even guile's necessarily as
f061d864d9
managed to expose.
I believe guile isn't actually configured correctly to expect
this directory, but since absolutely nobody has complained to
date as far as I can find & `gnutls` seems to be the only formula
using it this way the temptation is to leave it misconfigured
& use this directory for site schemes.
I don't really know the deeper issues around messing with Guile's
configuration so going for a minimal fix seems the safest option.
`any?` is not the opposite of `empty?`. Besides the case that
`[false, nil].any?` will return false, `any?`(O(n)) has much worse
performance than `empty?`(O(1)).
This prevents a link conflict during `brew upgrade` causing opt link
stuck to old version. At this point, users will have to run `brew switch`
to fix it.
Closes#533.
Signed-off-by: Xu Cheng <xucheng@me.com>
Require that the subdirectory in site-lisp match the formula name
exactly. This lets us provide better information in the caveats and
will make it easier for helper methods to write to the correct
location (as in in Homebrew/homebrew-emacs#13).
`Keg#app_installed?` only checks the formula prefix and `libexec/` for
.app bundles to determine if a formula provides any. This is used by
`Caveats#app_caveats` to generate an appropriate message. The same list
should be used by `brew linkapps` for consistency.
Reduce likelihood of future inconsistencies by creating `Keg#apps` and
using it in place of the duplicate code.
ClosesHomebrew/homebrew#45173.
Signed-off-by: Xu Cheng <xucheng@me.com>
Add `java` to `SHARE_PATHS` so that `HOMEBREW_PREFIX/share/java` is a folder with symlinks in it, rather than a symlink to a folder for a specific formula.
This way we avoid conflicts if multiple formulas put `jar` files in the
standard location `HOMEBREW_PREFIX/share/java`.
See also:
[pull request 44420](https://github.com/Homebrew/homebrew/pull/44420)
ClosesHomebrew/homebrew#44456.
Signed-off-by: Xu Cheng <xucheng@me.com>
After the formula gets renamed oldname opt is created and
it points to the linked keg. However if we then upgrade newname
oldname opt still points to the same keg it pointed before upgrade.
The commit fixes this behaviour thus that oldname opt links at the
same keg opt point.
If we have lib/python3.4/site-packages, which is a symlink to
HOMEBREW_PREFIX/lib/python3.4/site-packages, link will be confused. This
only appears after unlinking and relinking because this symlink is
created in post_install, which runs after the first link.
FixesHomebrew/linuxbrew#502.
ClosesHomebrew/homebrew#42891.
- The name of the subdirectory under site-lisp may not be exactly the
same as the name of the package
- `(normal-top-level-add-subdirs-to-load-path)` adds every subdirectory
of `default-directory` to the load-path, so users don't have to update
their load-path for every package they install.
ClosesHomebrew/homebrew#42309.
Work out what's text and what's not using `file`. Also, rename
`keg_fix_install_names` to `keg_relocate` because that's a more
accurate description of what it does now.
ClosesHomebrew/homebrew#41663.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
* Library/Homebrew/caveats.rb: add caveats comparable to other shells
* Library/Homebrew/formula.rb: define completion directory along the
conventions explained in the fish documentation for
$fish_complete_path
* Library/Homebrew/keg.rb: add fish shell to check function for
installed completions
ClosesHomebrew/homebrew#39828.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Packages supporting CMake may install configuration files for use
with CMake's find_package command. A recommended location for these
is `<prefix>/lib/cmake` which is not unique across packages. This
may cause issues for Formula using this location when their Keg
is linked.
As with pkg-config, explicitly create the `lib/cmake` folder when
linking a Keg that has installed folders/files to this location.
Also add testcase.
ClosesHomebrew/homebrew#38005.
Signed-off-by: Xu Cheng <xucheng@me.com>
When determining whether to remove a symlink during unlinking, we check
three things:
(a) Is the destination a symlink?
(b) Does the destination exist?
(c) Does the destination resolve to the source path?
However, since we know that the source path exists, (b) is guaranteed if
(a) and (c) are true. Thus checking (b) is unnecessary.
Similarly, when creating a new symlink during linking, we first check to
see if the link already exists by checking the same three criteria.
Again, checking (b) is unnecessary here.
See also the expanded test coverage in b52b579b.
Addendum: although we know that the source path exists during unlinking,
it doesn't matter. If the source path does not exist, then we still know
we have a broken symlink pointing into the keg we are unlinking, and
removing that symlink is still safe.
