Possibility to provide other formulae with a formula

[maki-chan]

A detailed description of the proposed feature

Other package managers like pacman for Arch Linux have the possibility to provide other packages via more specialized packages, e.g. ffmpeg-full with all features enabled does also provide the base package ffmpeg, so all needed dependencies are still met if only ffmpeg-full is installed (it would conflict with the ffmpeg package anyway).

Providing a class method .provides(name) for the Formula class similar to the .depends_on(name) method would be very helpful to tell the Homebrew system that a formula does provide the exact same functionality (i.e. also the same binaries/libraries) as another formula.

The motivation for the feature

After the removal of options in core formulae, it is hard to install formulae with optional features enabled while still satisfying all dependencies for other formulae. For example, I cannot install ffmpeg anymore with all features enabled like I did in the past. Creating another version with all features enabled in the custom tap maki-chan/homebrew-moreoptionals does not work because when I install the ffmpeg formula from there, even after tap-pin, updating depending formulae like audacious results in an error:

Error: ffmpeg is already installed from maki-chan/moreoptionals!
Please `brew uninstall ffmpeg` first.

The above mentioned feature would enable developers and power users to provide more feature-rich formulae, even if it was only "core formulae on steroids".

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

As mentioned above, it would create the possibility to provide more features for existing formulae without breaking dependencies and without the need for options in the core formulae. ffmpeg is maybe one of the most prominent examples, but there are most likely other formulae with features not enabled in the core repository but demanded by many people.

What alternatives to the feature have been considered

If there is already a method to tell brew that maki-chan/homebrew-moreoptionals/ffmpeg is the same as homebrew/homebrew-core/ffmpeg, then tell me and you can happily close this feature request. Otherwise, I am pretty sure there are enough users who would love a feature like this.

[RandomDSdevel]

@maki-chan:

     Efforts to maintain versions of Homebrew Core formulae with the options they used to have are currently being invested in portage-brew rather than here upstream.

[maki-chan]

I don't want to reintroduce options in core formulae and the suggested feature would also work if options were to be removed completely. As you can see, the more feature-rich ffmpeg I provide in my tap at maki-chan/homebrew-moreoptionals does not even use options, it just has more dependencies and enables more features.

It is still a valid feature request in my opinion, the removal of options in the core formulae was just the trigger for a definitive need of the .provides(name) feature.

Furthermore, it may be that I am blind, but I cannot really see how portage-brew does help me in my current situation, at least for now. It looks as you would like to establish a second brew ecosystem and that's not really what I would want to have.

[RandomDSdevel]

@maki-chan:

⋮

Furthermore, it may be that I am blind, but I cannot really see how portage-brew does help me in my current situation, at least for now. It looks as you would like to establish a second brew ecosystem and that's not really what I would want to have.

     It's not really what we want, either, but upstream hasn't been meeting the kinds of needs we want portage-brew to fulfill.

[MikeMcQuaid]

ffmpeg-full with all features enabled does also provide the base package ffmpeg, so all needed dependencies are still met if only ffmpeg-full is installed (it would conflict with the ffmpeg package anyway).

This is the best way to do this in Homebrew too: create a new ffmpeg formula rather than reusing the ffmpeg name.

Did you check any of the docs for this (to be clear: it's not in there yet)? I'm wondering where would be best to document this to avoid future confusion. Thanks!

If there is already a method to tell brew that maki-chan/homebrew-moreoptionals/ffmpeg is the same as homebrew/homebrew-core/ffmpeg, then tell me and you can happily close this feature request.

I'm afraid we won't add this because it makes it easy for a user to install a formula from a tap which breaks our formulae due to incompatibilities which then makes it hard for us and them to debug the issue. To repeat above: the best bet is to use a different name.

     Efforts to maintain versions of Homebrew Core formulae with the options they used to have are currently being invested in portage-brew rather than here upstream.
     It's not really what we want, either, but upstream hasn't been meeting the kinds of needs we want portage-brew to fulfill.

@RandomDSdevel With respect, please let the Homebrew project state what we will or will not do. We're happy to add your fork to "Interesting Taps and Forks" when it's ready for public consumption but I'd ask you refrain from this sort of commentary on our issue tracker, thanks.

[maki-chan]

@MikeMcQuaid For the case you do not want to add a feature like that, you could add a new paragraph in the How to Create and Maintain a Tap documentation. Create a note there that formulae should not try to overwrite core formula names and it would be great to also mention in a small example how to provide alternative binary names. With your solution, it will be needed to use the ffmpeg package from core which will provide a ffmpeg binary, but my custom package ffmpeg-full will need to provide a ffmpeg-full binary to avoid confusions and provide further compatibility.

Or is it possible to unlink the core ffmpeg package and link the custom ffmpeg-full package and the dependencies will still be satisfied? (Did not try that yet, will do asap.)

[maki-chan]

It seems to be indeed allowed to unlink a dependency and it still counts as satisfied, so I can link my ffmpeg-full package and leave the dependency ffmpeg unlinked. Though I do not know if this is intended by brew at all, it does work for now.

[MikeMcQuaid]

Glad you've found a solution. That is broadly intended to work by Homebrew (dependencies should not rely on linkage) but might not 100% of the time (which is why brew doctor may complain but you can ignore this). I'll make a note to add docs for this, good idea.