Main reasons for boneyard:
* As this formula now stands, it fails to build (with a mysterious
error) against FFmpeg 3.0 (#49178);
* This is a GUI-only tool (look at its awkward test), so it doesn't
quite belong to core to begin with; and due to the build issue above,
work is needed if it is to be revived in homebrew/gui;
* There's not enough interest, seeing that we are two releases or half a
year behind, and no user even proposed a version bump;
* Upstream's preferred method of installation is the app bundle (which
seems to be a much more complete solution, given the app bundle's
size), distributed in binary disk images.
More discussions in Homebrew/homebrew#49178.
ClosesHomebrew/homebrew#49378.
Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>
* Blocks writing of new files via accidental typos, etc, which the normal open("blah", "a") doesn't.
* Where files don't exist they should ideally be using `(buildpath/"dog").write` instead of open("blah", "a") already.
* It's a bit less cluttered looking if you need several writes to different files in the formula, IMO.
In theory, letting these be set once wasn't an awful idea because it allows
users choice on where Perl modules end up.
In reality, as we've moved closer to sandboxing and at the same time accepted more
perl binding options into formulae it has been exposed as something of a hellraiser.
It's not that uncommon for Perl users to set a custom `INSTALL_BASE` in the ENV which
means we end up with quite a few formula that fail hard with this sort of error:
```
Only one of PREFIX or INSTALL_BASE can be given. Not both.
```
The other common error, which we discovered via sandboxing, is that the Perl modules
end up outside Homebrew's control which means we don't automatically remove them
when the package is removed. Sandboxing blocks this, which means when we eventually
move to enable that by default for users as well as CI it'll quickly become a
prominent issue.
The recent updates to OSXFuse include two new elements that get flagged by
`brew doctor`. Adding them here so it's consistent with how we handle the rest
of OSXFuse.
ClosesHomebrew/homebrew#49372.
Boneyarding because:
1. Not compatible with FFmpeg 3.0 (#49178);
2. Not developed in the open, only release tarballs are available, so
tracking progress is hard;
3. Latest release is from April 2013;
4. Has to join a mailing list to report bugs, the archive of which was
last built in 2014.
In summary, there's no evidence that this library is not abandoned.
See also discussions in Homebrew/homebrew#49178.
ClosesHomebrew/homebrew#49268.
Signed-off-by: Dominyk Tiller <dominyktiller@gmail.com>
Groups make it easier to get an overview of the coverage without having
to scan through a single very long list of files. They also display a
possibly helpful per-group coverage.
The project name is normally derived from the `root` directory which
happens to be `Library` in our case, thus make it explicitly `Homebrew`.
ClosesHomebrew/homebrew#49303.
Signed-off-by: Martin Afanasjew <martin@afanasjew.de>
This should help to prevent situations where a user accidentally ends up
"stranded" in a branch indefinitely.
Additionally, the stash is never popped automatically at the end of a
successful update, but the stash-pop message is printed if something is
stashed.
When an interrupt occurs, the original behavior is still in place
(switch back to the old branch and revision, and pop the stash), though
this could be changed as well.
This commit modifies the behavior of both `brew update` and
"update-bash.sh" in the manner described above.
The idea for this approach is from Mike McQuaid.
Issue Homebrew/homebrew#48812ClosesHomebrew/homebrew#48993.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
We haven't seen this for a fair while since Apple pushed further updates to the
SIP mechanism and believe it to be far less of an issue than it was previously.
If you encounter further failure, please file an Issue and we'll be happy to
help! At the moment though this advice is making people think there _will_ be an
issue at some point, which isn't generally proving the case.
The current code doesn't work with releases that have more than one
digit in the third group, i.e.:
.../releases/download/1.2.3/... works
.../releases/download/1.2.34/... doesn't work
ClosesHomebrew/homebrew#49255.
Signed-off-by: Baptiste Fontaine <batifon@yahoo.fr>
`bin/brew` is getting a bit bloated and it's annoying to open all of
`HOMEBREW_PREFIX` in your editor of choice and have it search through
the `Cellar`. Let's instead keep the bare minimum in `bin/brew` and
move the rest to `Library`.
ClosesHomebrew/homebrew#49185.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
Return true if given path would present a Formula file in this Tap.
Accepts both absolute path and relative path (relative to this Tap's path)
It offer an abstraction such that caller would not need to worry about
low level file system in the tap.
It will be used in `brew pull` and `brew update`.
ClosesHomebrew/homebrew#49191.
Signed-off-by: Xu Cheng <xucheng@me.com>
Also, rename the existing updater to `update-ruby` to allow using as
a fallback. It will eventually be removed.
ClosesHomebrew/homebrew#49109.
Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
The Telepathy formulae are being shipped off to the boneyard.
1) The number of downloads per formula in terms of Bottles is less than 30 in
the space of 3 months.
2) Two of them were moved onto development releases in November and nobody noticed.
3) telepathy-gabble's executable has been broken since submission and nobody noticed.
4) Making telepathy-gabble's executable function requires significant changes to
d-bus, including enforcing a mandatory X11 dependency on telepathy-gabble users.
5) It's not particularly simple to write tests for the formulae which means they're
more likely to break without CI noticing.
ClosesHomebrew/homebrew#49052.
Zhiming Wang