Skip to content
This repository has been archived by the owner on Jul 4, 2023. It is now read-only.

--force-bottle not propagated to dependencies #41938

Closed
sjackman opened this issue Jul 20, 2015 · 10 comments
Closed

--force-bottle not propagated to dependencies #41938

sjackman opened this issue Jul 20, 2015 · 10 comments

Comments

@sjackman
Copy link
Member

From @schmurfy on July 20, 2015 10:38

When you force bottle usage the depencies will be installed from sources even if the package is available, it looks like the flag is now passed to "brew install" for such dependencies.
I am not familiar enough (yet) to fix that myself but maybe soon :)

Copied from original issue: Linuxbrew/legacy-linuxbrew#489

@sjackman
Copy link
Member Author

From @schmurfy on July 20, 2015 12:58

is there a way to inverse the behavior so that by default it uses bottles if available and a flag would force to build from sources ?

@sjackman
Copy link
Member Author

Reassigning to Homebrew/homebrew.

@mistydemeo
Copy link
Member

is there a way to inverse the behavior so that by default it uses bottles if available and a flag would force to build from sources ?

This is how bottles already work. A bottle will be used unless one of the following conditions is met:

  1. The user has Homebrew installed in a non-default prefix and the bottle is not relocatable,
  2. The user requested non-default options, or
  3. The user passes --build-from-source or -s, or has HOMEBREW_BUILD_FROM_SOURCE set in their environment.

@sjackman
Copy link
Member Author

Linuxbrew has the additional requirement that glibc and patchelf be installed. Sorry, I should have clarified that before moving the issue. The question I was reassigning (in my head) is
Can/should brew install --force-bottle be applied to the dependencies of the requested package?

@MikeMcQuaid
Copy link
Member

--force-bottle isn't really something that should be used often. If I had my way it probably wouldn't even be user visible.

@mistydemeo
Copy link
Member

What is the user's usecase? Why are they using --force-bottle? I wonder if this is something that can be solved in another way. Like Mike says, --force-bottle is something you generally want to avoid because it means you either get a non-working install or one that doesn't actually respect the user's options.

@sjackman
Copy link
Member Author

@schmurfy Why do you need --force-bottle?
My guess is that he doesn't have glibc or patchelf installed but wants to use the Linuxbrew bottles anyways. They might work if your system is sufficiently current.

@sjackman
Copy link
Member Author

Looks like I moved this issue prematurely, as the use case is rather specific to Linuxbrew. Thanks for your input, Mike and Misty, in any case.

@schmurfy
Copy link
Contributor

in fact the usecase is really with linuxbrew so I am not sure which part applies to homebrew itself but in linuxbrew the current default behavior is to always install from source for reasons mentioned above by @sjackman, this totally makes sense until a decent solution is found but in my case I am building my own bottles targeted at known systems I installed and I so the behavior I wish to have is reversed (and effectively the Homebrew one).

All this leads to my need of "--force-bottle" to install from the bottle unless I want to build from sources, the issue is that currently "--force-bottle" only applies to the recipe you are installing, if a dependency needs to be installed it will be from sources which makes the dependencies system rather useless in my case and require installing each by hand:

$ brew install dependency1
$ brew install dependency2
$ brew install final_app

I tried to look at the code to patch this myself but following the code paths is quite hard and I didn't managed to.

@MikeMcQuaid
Copy link
Member

Ok, this is a Linuxbrew-specific issue so closing.

@Homebrew Homebrew locked and limited conversation to collaborators Jul 10, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants