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.
